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PREFACE 


This  paper  was  prepared  for  the  Ballistic  Missile  Defense  Organization  (BMDO)  as 
a  follow-on  effort  for  the  Task  Order  “Software  Testing  of  Strategic  Defense  Systems.”  It 
fulfills  an  objective  of  this  subtask,  to  assist  the  BMDO  in  planning,  executing,  and  moni¬ 
toring  software  testing  and  evaluation  research,  development,  and  practice. 

This  p^)er  is  a  supplement  to  IDA  Paper  P-2769,  An  Examination  of  Selected  Soft¬ 
ware  Tools:  1992.  It  reports  the  results  of  examining  another  8  static  and  dynamic  analysis 
tools  in  addition  to  the  27  testing  tools  originally  presented  in  P-2769. 

This  paper  was  reviewed  by  Dr.  Dennis  Fife,  a  research  staff  member  of  the  Institute 
for  Defense  Analyses. 
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FOREWORD 


This  report  is  a  continuation  of  IDA  Paper  P-2769,  An  Examination  of  Selected  Soft¬ 
ware  Testing  Tools:  1992  [Youngblut  1992].  From  Part  I  of  P-2769,  the  introductory  sec¬ 
tions  (Sections  1  through  3)  also  apply  to  the  current  report  and,  in  the  interests  of  space, 
have  not  been  repeated.  Section  4,  “Approach  and  Methods,”  of  P-2769  identified  the 
examined  tools  and  the  examination  approach.  In  this  update.  Table  1  identifies  the  tools 
recently  examined  and,  for  convenience,  the  original  tool  list  is  repeated  in  Table  2.  An 
additional  trial  Ada  program  was  included  to  demonstrate  tool  capabilities  for  testing  con¬ 
current  Ada  software,  the  Real-Ume  Temperature  Sensor  as  described  by  Nielsen  [1988]. 


Table  1. Tools  Examined  In  this  IDA  Study 


TOOL  NAME 

TOOL  SUPPLIER 

LANGUAGES 

SUPPORTED 

test 

CAPABILITIES 

Ada 

C++ 

Fortran 

Other 

Test  Management 

Problem  Reporting 

Static  Analysis 

1 

-< 

JH 

B 

1 

a 

ACT 

McCabe  A  Assodates 

u 

U 

U 

EM 

u 

u 

EM 

Ada-ASSURED 

GianunaTech,  Inc. 

u 

EM 

AdaTEST 

Information  ftocessing  Ltd. 

u 

U 

Battlemap^ 

McCabe  &  Associates 

a 

EM 

EM 

EM 

u 

EM 

EM 

CodeBreaker 

McCabe  &  Associates 

u 

EM 

U 

EM 

u 

EM 

ZJ 

METRIC* 

Software  Research,  Inc. 

EM 

EM 

U 

EM 

1 

EM 

“1 

McCabe  Instrumentation  Tool 

McCabe  A  AssodUes 

u 

EM 

EM 

EM 

u 

EM 

u 

SLICE 

McCabe  A  Assodates 

!!■ 

EM 

_ 

__ 

u 

_ 

u 

a.  Used  with  McCabe  Instnimentation  Tool  for  gnqphical  rqxMting  of  unit  coveiage. 

b.  Used  with  McCabe  Instnimentation  Tool  for  gr^ihical  reporting  of  design  subtree  coverage. 

c.  New  component  <£  the  Software  TestWcxks  (STW)  toolsk. 

Sections  in  P-2769  on  static  and  dynamic  analysis  are  rq)eated  here,  extended  with 


information  for  the  newly  examined  tools.  Since  these  new  tools  did  not  provide  explicit 
support  for  test  management  or  problem  reporting,  the  corresponding  sections  from  P-2769 


V 


have  not  been  repeated.  The  findings  remain  unchanged  and  also  are  not  repeated.  Part  II 
presented  tool  and  supplier  profiles  for  the  previously  examined  tools.  This  has  been  updat¬ 
ed  to  include  information  on  the  new  tools.  Tlte  remainder  of  Part  II  consists  of  tool  exam¬ 
ination  reports  that  supplement  the  examination  reports  provided  in  P-2769. 


Table  2.T00IS  Examined  In  the  Previous  IDA  Study 


TOOL  NAME 


ADADL  Processor 


AdaQuest 


AutoFlow-Ada 


DDTs 


EDSA 


GrafBrowse 


LDRA  Testbed 


Logiscope 


MALPAS 


Metrics  Manager 


QES/Manager 


QualCen 


S-TCAT 


SQA;Manager 


SRE  Toolkit 


SoftTest 


T-PLAN 


TBGEN 


TCAT 


TCAT-PATH 


TCMON 


TDGen 


TSCXJPE 


TST 


Test/Cycle 


TestGen 


LANGUAGES 

SUPPORTED 


TEST 

CAPABILITIES 


ee 

s  I  R 

I  I  t  t 

I  „  I  I  I  I 

+  1  §  e  ^  s  S. 

U  £  O  ^  £  S  Q 


Software  Systems  Design 


General  Research  Corp. 


AutoCASE  Technology 


QualTrak  Corp. 


Array  Systems  Computing,  Inc. 


Software  Systems  Design 


Program  Analysers.  Ltd. 


Vetilog.  Inc. 


TA  Consultancy  Services,  Ltd. 


Computer  Power  Group,  Inc. 


QuaUty  Engineering  Software.  Inc. 


Software  Systems  Design 


Software  Research,  Inc. 


Software  Quality  Automation 


Software  Quality  Engineering 


Bender  &  Associates 


Programming  Environments,  Inc. 


Software  Quality  Assurance,  Ltd. 


Testwell  Oy 


Software  Research,  Inc. 


Software  Research,  Inc. 


Testwell  Oy 


Software  Research,  Inc. 


Software  Research.  Inc. 


STARS  Foundation  Repository 


Computer  Power  Group,  Inc. 


Software  Systems  Design 
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7.  STATIC  ANALYSIS 
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Static  analysis  is  used  to  determine  the  presence  or  absence  of  particular,  limited 
classes  of  errors,  to  produce  certain  kinds  of  software  documentation,  and  to  assess  various 
characteristics  of  software  quality.  Unlike  dynamic  analysis,  static  analysis  can  sometimes 
be  performed  on  incomplete  or  partly  development  products  and  does  not  necessitate  costly 
test  environments.  It  cannot,  however,  replace  dynamic  analysis,  although  it  can  be  used  to 
guide  and  focus  dynamic  testing.  Previously,  Table  1-1  and  Table  1-2  identified  19  tools  as 
supporting  static  analysis.  The  functions  provided  by  these  tools  are  summarized  in  Table 
7-1.  (For  convenience,  this  and  all  subsequent  tables  use  shading  to  highlight  the  newly 
examined  tools.) 

7.1  Complexity  Analysis 

Complexity  measures  can  be  put  to  various  test-related  uses.  McCabe  [1982]  has 
developed  a  method.  Structured  Testing,  that  uses  cyclomatic  complexity  to  guide  the 
selection  of  a  minimum  set  of  required  paths  to  test.  Complexity  measures  are  also  used  to 
estimate  the  number  of  defects  present  in  a  piece  of  software,  to  identify  pieces  of  code  that 
are  potentially  defective,  and  to  estimate  needed  development  effort 

Models  for  estimating  program  complexity  have  been  based  on  various  character¬ 
istics  of  software  structure  and  semantics.  The  best-known  set  of  complexity  measures  are 
all  applied  at  the  program  unit  level.  They  are  McCabe’s  cyclomatic  complexity  metrics 
and  Halstead’s  software  science  metrics  [1977].  Whereas  cyclomatic  complexity  is  control 
oriented,  the  Halstead  metrics  are  text  oriented.  As  well  as  variations  on  each  of  these  mea¬ 
sures,  there  are  many  other  unit-level  measures.  In  contrast,  relatively  few  measures  for 
assessing  design-level  complexity  have  been  proposed.  Perhaps  the  most  common  design- 
level  measures  are  those  developed  by  Mohanty  [1976]  that  are  based  on  a  call  graph  and 
basic  subtrees,  a  variation  on  cyclomatic  complexity.  Measures  for  assessing  requirements 
complexity  are  similarly  scarce  and  not  supported  by  any  of  the  examined  tools.  Table  7-2 
identifies  the  different  types  of  complexity  measures  that  are  provided. 
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Table  7-1.  Static  Analysis  Capabilities  of  Examined  Tools 


TOOL  NAME 

Complexity  Analysis  | 

Data  Flow  Analysis  | 

Control  Flow 
Analysis 

1  Information  Flow  Analysis  | 

1  Standards  Conf.  Analysis  | 

1  Quality  Analysis  | 

1  Cross-Reference  Analysis  | 

1  Browsing  | 

Symbolic  Evaluation  | 

Specification  Compliance  | 

C 

e 

£ 

t 

Bm 

Structure  Analysis 

Path  Analysis 

Code  Statistics 

Flowgraph  Generation 

Call  Graph  Generation 

ADADL  Processor 

El 

El 

El 

AdaQuest 

El 

B 

B 

AutoHow-Ada 

El 

B 

El 

EDSA 

El 

El 

El 

El 

El 

GrafBrowse 

El 

El 

LDRA  Testbed 

El 

El 

El 

El 

El 

El 

El 

El 

El 

El 

El 

Logiscope 

El 

El 

El 

El 

El 

El 

El 

El 

MALPAS 

El 

El 

El 

El 

El 

El 

El 

El 

QualGen 

El 

S-TCAT 

El 

El 

El 

El 

TCAT 

El 

El 

El 

El 

TCAT-PATH 

El 

D 

El 

El 

El 

El 

TST 

El 

El 

El 

TestGen 

El 

El 

El 

n 

ACT 

T 

' 

m 

m 

m 

m 

m 

m 

m 

■ 

a 

■ 

■ 

m 

m 

m 

m 

;Fi 

\ . j 

LJ 

1  'V 

u 

i _ : 

F 

ipi 

□ 

M 

m 

m 

m 

S 

a 

a 

m 

m 

m 

m 

m 

m 

H 

H 

1 

M 

:  ^ 

i  ^ 

■ 

il 

LJ 

1 

I 

m 

m 

m 

U 

n 

LI 

m 

■ 

F  -  Future  capability 


Twenty  years  of  theoretical  and  empirical  evaluations  have  failed  to  produce  con¬ 
sistent,  hard  evidence  of  the  accuracy  of  particular  measures  or  on  the  respective  value  of 
other  measures.  Consequently,  these  measures  should  be  used  as  indicators  rather  than  as 
absolute  measures  of  software  properties. 
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Table  7-2.  Supported  Complexity  Measures 


Unit  Level 


■S  ^  i 

S>  s  s  o  1  , 

§  §■«  i 

^  w  U  i  c  «  fc 


1 1 1  ^ 
BB  SB  g  'S 

u  ^  S 

1  a  a 


Cj  B  C  *  k  S 

4r  U  &  E  <9  Bi£ 


t  ^ 

a  £ 


I  I  1  1  £  5  i 
i  |i  1 1 II 

a  a  r  >  rw?  ^ 


eo  u  u  iS 


u  Gd  a.  a.  a.  M 


F  •  Future  capability 

7.2  Data  Flow  Analysis 

Data  flow  analysis  is  based  on  consid^ation  of  the  sequences  of  events  that  occur 
along  the  various  paths  through  a  program.  It  is  used  to  detect  data  flow  anomalies,  of  which 
three  types  are  commonly  recognized:  (1)  a  variable  whose  value  is  undefined  is  refer¬ 
enced,  (2)  a  defined  variable  is  redefined  before  it  is  referenced,  or  (3)  a  defined  variable  is 
undefined  before  it  is  referenced.  While  the  first  of  these  indicates  an  actual  program  defect, 
the  second  and  third  types  of  anomaly  may  indicate  questionable  variable  use  rather  than 
specific  defects. 

Since  the  analysis  technique  assumes  that  all  paths  through  the  program  are  feasi¬ 
ble,  some  reported  anomalies  may  be  superfluous.  Data  flow  analysis  also  can  be  used  to 
categorize  procedure  parameters  as  referenced  only,  defined  only,  both  defined  and  refer¬ 
enced,  or  not  used. 

LDRA  Testbed,  MALPAS,  and  EDS  A  support  static  data  flow  analysis.  LDRA 
Testbed  performs  weak  data  flow  analysis  to  identify  data  flow  anomalies  of  the  types  men- 
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tioned  above.  It  also  analyzes  procedures  calls  across  procedure  boundaries  to  report  on 
procedure  parameter  use.  MALPAS  refines  the  classification  of  data  flow  anomalies.  For 
example,  a  data  variable  that  is  redefined  before  it  is  referenced  may  be  classified  as  either 
an  instance  where  data  is  written  twice  without  an  intervening  read,  or  as  data  being  written 
with  no  subsequent  access  on  a  given  path.  Given  a  list  of  procedure  input  and  ouq)ut 
parameters,  MALPAS  compares  these  with  the  classes  of  data  to  produce  a  table  of  possible 
errors.  EDSA  uses  interactive  data  flow  analysis  to  facilitate  program  browsing. 

7.3  Control  Flow  Analysis 

Control  flow  analysis  is  a  process  of  examining  a  program  structure  and  ide  ^ving 
major  features  such  as  entry  and  exit  points,  loops,  unreachable  code,  and  paths  ha 
program.  This  information  can  be  used  to  detaniine  program  complexity  and  to  aid  ui  plan¬ 
ning  a  dynamic  test  strategy.  It  can  help  to  decide  on  strategies  for  further  analysis,  for 
example,  to  identify  where  it  might  be  beneficial  to  partition  the  code  to  reduce  the  number 
of  paths  and,  hence,  facilitate  semantic  analysis.  The  results  of  control  flow  analysis  can 
also  be  used  to  prepare  a  diagram  of  the  program  structure  that  can  aid  a  user  in  document 
ing  and  understanding  a  piece  of  software. 

Control  flow  analysis  is  provided  by  the  majority  of  tools  that  support  static  analy¬ 
sis,  MALPAS,  TestGen,  LDRA  Testbed,  and  the  TCAT  family  all  report  on  unreachable 
paths.  These  may  be  generated  as  a  result  of  program  syntax,  for  example,  as  a  result  of  end 
if  statements,  or  the  position  of  a  return  statement  Even  though  they  do  not  necessarily 
imply  a  defect  the  occurrence  of  unreachable  paths  should  be  checked.  Some  of  the  exam¬ 
ined  tools  go  farther.  LDRA  Testbed,  for  example,  also  reports  on  unreachable  branches 
and  other  structural  units. 

Several  of  the  tools  use  control  flow  analysis  to  generate  a  graphical  representation 
of  a  program’s  structure  as  a  logical  flow  chart  or  directed  graph.  This  allows  visual  inspec¬ 
tion  of  program  structure  and  complexity,  and  can  facilitate  program  understanding  at  the 
unit  level.  ACT,  AutoFlow-Ada,  Battlemap,  LDRA  Testbed,  Logiscope,  TCAT,  and  TCAT- 
PATH  all  generate  fairly  sophisticated  graphs  of  a  program’s  structure.  AutoFlow-Ada,  in 
particular,  provides  a  user  with  considerable  flexibility  in  genCTating  a  high-quality  graph¬ 
ical  flow  chart.  TestGen  uses  textual  facilities  to  produce  a  more  primitive  graph.  Although 
MALPAS  docs  not  directly  produce  a  directed  graph,  its  list  of  nodes,  with  identification  of 
successor  and  predecessor  nodes,  helps  a  user  to  draw  this  graph.  Graphical  representation 
of  the  calling  relationship  between  program  units  also  facilitates  program  understanding. 
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Battlemap,  GrafBrowse,  LDRA  Testbed,  Logiscope,  and  S-TCAT  generate  call  graphs  or 
call  trees. 

The  identification  of  paths  through  a  program  is  useful  for  estimating  the  resources 
needed  for  dynamic  analysis  and  then  guiding  this  testing.  ACT,  AdaQuest,  LDRA  Testbed, 
Logiscope,  MALPAS,  TCAT-PATH,  TST,  and  TestGen  all  provide  this  capability.  Even 
more  useful,  ACT,  LDRA  Testbed,  Logiscope,  and  TestGen  explicitly  identify  the  values 
of  logical  conditions  necessary  to  cause  particular  paths  to  be  followed  (in  the  case  of  ACT, 
these  are  the  set  of  paths  required  for  McCabe’s  Structured  Testing  method).  Battlemap 
identifies  the  design  subtrees  that  form  the  integration  structure  of  a  program  and  also  the 
values  of  logical  conditions  necessary  to  cause  particular  subtrees  to  be  followed  (in  this 
case,  the  tool  distinguishes  between  the  full  set  of  design  subtrees  and  the  more  limited  set 
of  cyclomatic  subtrees). 

ACT,  AdaTEST,  Battlemap,  Logiscope,  METRIC,  TCAT,  TCAT-PATH,  and  S- 
TCAT  report  on  various  code  statistics.  These  statistics  range  firom  measures  such  as  the 
total  number  of  dynamic  memory  allocations,  to  measures  of  the  average,  minimum,  and 
maximum  path  length.  EDS  A  provides  interactive  control  flow  analysis  to  facilitate  brows¬ 
ing  along  program  paths. 

MALPAS,  LDRA  Testbed,  and  Logiscope  perform  structure  analysis  to  verify  a 
program’s  conformance  to  the  principles  of  structured  programming.  Here  LDRA  Testbed 
matches  templates  of  acceptable  structures  with  the  directed  graph  of  a  program  on  a  mod¬ 
ule  by  module  basis.  Matching  structures  are  successively  collapsed  to  a  single  node  until 
either  a  single  node  is  left,  indicating  a  structured  program,  or  an  irreducible  state,  indicat¬ 
ing  an  unstructured  program.  MALPAS  and  Logiscope  perform  a  similar  reduction  to  eval¬ 
uate  the  structure. 

CodeBreaker  is  unusual  in  that  it  is  designed  to  serve  a  single  purpose.  It  uses  struc¬ 
ture  analysis  to  compare  the  design  structures  of  two  (sub)program5  or  to  compare  the  con¬ 
trol  structures  of  two  individual  modules.  Any  discrepancies  between  the  two  are  identified. 

7.4  Information  Flow  Analysis 

Information  flow  analysis  is  used  to  examine  program  variable  interdependencies. 
This  helps  to  isolate  inadvertent  or  unwanted  dq)endencies,  to  indicate  how  a  program  can 
be  broken  down  into  subprograms,  and  to  identify  the  scope  of  program  changes.  For  secu¬ 
rity  applications,  it  can  be  used  to  aid  the  identification  of  spurious  or  unknown  code.  Addi- 


tionally,  it  supports  dynamic  testing  by  identifying  which  inputs  need  to  be  exercised  to 
affect  which  outputs. 

Both  LDRA  Testbed  and  MALPAS  provide  this  capability.  Currently  LDRA  Test¬ 
bed  is  limited  to  identifying  backward  dependencies  on  a  procedure  by  procedure  basis  and 
characterizes  variables  as  strongly  or  weakly  dependent.  Future  versions  of  LDRA  Testbed 
will  include  forward  dependencies  to  identify  variables  that  can  be  affected  by  a  particular 
input  variable.  It  will  also  support  information  flow  dependence  assertions  to  allow  com¬ 
parison  of  expected  dependencies  with  actual  dependencies. 

MALPAS  identifies  all  of  a  program’s  inputs  and  examines  each  executable  path  to 
identify  dependencies  for  each  output  variable.  These  dependencies  include  the  input  vari¬ 
ables,  constants,  and  conditional  statements  on  which  it  depends.  It  reports  on  program  unit 
inputs  and  outputs,  which  may  be  more  than  those  passed  as  parameters.  MALPAS  also 
identifies  redundant  statements. 

7.5  Standards  Conformance  Analysis 

Auditors  are  used  to  check  the  conformance  of  a  program  to  a  set  of  standards.  For 
Ballistic  Missile  Defense  (BMD)  software,  the  Software  Productivity  Consortium  (SPC) 
Ada  Quality  and  Style:  Guidelines  for  Professional  Programmers  (SPC  1991]  defines  the 
required  standards.  Ada-ASSURED  supports  these  guidelines,  as  does  ADAMAT,  dis¬ 
cussed  in  the  Ballistic  Missile  Defense  Organization  (BMDO)  Computer  Resources  Work¬ 
ing  Group  (CRWG)  study. 

LDRA  Testbed  checks  conformance  to  a  set  of  standards  of  interest  to  the  program¬ 
ming  community;  this  includes  much  of  the  Safe  Ada  Subset  Individual  standards  can  be 
disabled  and  the  user  can  weight  particular  standards  or  specify  acceptance  limits,  where 
appropriate.  TST  reports  on  conformance  to  a  set  of  portability  standards. 

7.6  Quality  Analysis 

As  already  mentioned,  several  tools  report  on  particular  quality  characteristics  such 
as  complexity  and  compliance  with  standards.  There  are,  however,  many  other  quality 
characteristics  that  provide  insight  into  code  maintainability  and  portabiliQr,  for  exan:q)le. 

One  of  the  examined  tools,  Logiscope,  ranploys  the  Rome  Air  Development  Center 
(RADC)  quality  metrics  model  to  allow  user-defined  quality  measurement  at  three  levels 
of  abstraction  [RADC  1983].  At  the  lowest  level  of  the  model,  the  user  can  defined  upper 
and  lower  bounds  for  a  predefined  set  of  primitive  metrics.  Logiscope  distinguishes 
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between  unit-level  metrics  and  architectural  metrics,  reporting  on  both.  The  user  can  then 
specify  algorithms  to  weight  and  combine  the  primitive  metrics  into  composite  metrics. 
These  composite  metrics  are,  in  turn,  used  to  define  quality  criteria  that  allow  classifying 
components  as,  for  example,  accepted  or  rejected,  based  on  their  computed  quality  values. 

QualGen  analyses  both  design  and  code  complexify  and  currently  interfaces  with 
Lotus  1-2-3  for  qualify  reporting.  It  provides  some  200  primitive  metrics  which,  via  Lotus, 
can  be  combined  into  user-defined  higher  level  measures.  AdaTEST  provides  a  similar 
facility  through  the  use  of.csv  files.  Software  Systems  Design,  the  developer  of  QualGen, 
is  currendy  mapping  the  correspondence  of  QualGen  metrics  to  the  SPC  Ada  style  guide. 

7.7  Cross-Reference  Analysis 

The  information  acquired  from  cross-referencing  program  entities  serves  many  pur¬ 
poses.  Perhaps  one  of  the  most  important  of  these  is  identifying  the  scope  of  a  program 
change  or  aiding  in  the  diagnosis  of  a  software  failure. 

The  ADADL  Processor  provides  extensive  cross-referencing  capabilities.  It  reports 
on  the  cross-referencing  between  program  units,  objects,  and  types.  It  also  reports  on  the 
occurrence  of  with  and  pragma  statements;  the  occurrence  of  interrupts,  exceptions,  and 
generic  instantiations;  and  the  use  of  program  unit  renaming.  LDRA  Testbed  cross-refer¬ 
ences  all  data  items  and  classifies  them  as  global,  local,  or  parameter  and  also  cross-refer¬ 
ences  procedure  usage.  METRIC  identifies  all  generic  units,  the  number  of  times  they  are 
instantiated,  and  the  instantiating  unit  Through  its  browsing  capabilities,  EDSA  provides 
interactive  cross-referencing  of  data  items  and  Ada  objects.  BatUemap  cross-references 
program  units  in  terms  of  their  calls-to  and  called-by  relationships,  it  also  provides  context 
and  index  listings  to  identify  the  files  in  which  particular  units  are  stored. 

7.8  Browsing 

A  browser  facilitates  program  understanding  by  allowing  the  user  to  create  and 
present  different  views  of  the  software.  This  may  include  views  that  show  the  same  piece 
of  software  at  different  stages  of  development  and  views  that  omit  some  information  in 
order  to  focus  on  other  details.  A  browser  also  may  provide  the  user  with  the  ability  to  fol¬ 
low  the  control  flow  or  data  flow.  These  capabilities  may  be  used  for  several  purposes,  for 
example,  to  aid  in  reviewing  a  program  or  in  diagnosing  the  cause  of  a  software  failure. 

EDSA  focuses  on  browsing  source  code  at  the  unit  level;  it  allows  browsing  for¬ 
ward  or  backward  via  data  flow  or  control  flow.  The  user  can  construct  views  that  suppress 
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or  omit  irrelevant  code  details  to  help  the  user  to  focus  on  the  concern  at  hand.  Special 
annotations  are  available  to  keep  track  of  the  progress  of  formal  code  verification.  Ada- 
ASSURED  provides  similar  capabilities  with  navigation  based  on  control  structure.  Graf- 
Browse  chiefly  operates  at  the  integration  level.  Here  the  user  can  move  through  graphical 
invocation  hierarchies  (or  declaration  or  call-by  hierarchies),  pulling  up  the  relevant  pieces 
of  code  as  required.  Battlemap  and  the  TCAT  family  of  coverage  analyzers  also  allow  mov¬ 
ing  between  graphical  depictions  of  program  and  module  structure  and  the  associated 
source  code. 

Although  not  examined  in  the  course  of  this  work,  the  new  version  of  Logiscope 
also  supports  source  code  browsing. 

7.9  Symbolic  Evaluation 

This  type  of  static  semantic  analysis  provides  a  more  complete  examination  of  a 
program’s  operation.  Instead  of  actual  input  data,  symbols  such  as  variable  names  are  used 
to  simulate  program  execution.  This  allows  the  reporting  of  the  mathematical  relationships 
between  inputs  and  outputs  for  each  semantically  possible  path.  It  has  three  primary  uses. 
The  relationships  can  be  compared  against  a  program  specification  to  check  for  consisten¬ 
cy.  The  identified  path  condition,  together  with  the  expression  detailing  the  set  or  range  of 
input  data  which  causes  this  path  to  be  executed,  supports  test  data  generation.  Finally,  the 
relationships  can  aid  in  determination  of  the  expected  ouq>ut  for  a  set  of  test  data.  Only 
MALPAS  provides  this  very  useful  capability. 

7.10  Specification  Compliance  Analysis 

Specification  compliance  analysis  takes  semantic  analysis  a  step  further  by  auto¬ 
matically  comparing  a  program  against  its  formal  specification  to  identify  deviations.  This 
type  of  analysis  is  very  powerful,  but  requires  additional  work  on  the  behalf  of  the  user. 

Here  again,  MALPAS  was  the  only  examined  tool  that  provides  this  capability.  It 
requires  program  specification  details  to  be  embedded  in  its  intermediate  language.  (These 
details  may  already  be  available  if  a  formal  specification  language  such  as  Z  or  the  Vienna 
Development  Method  (VDM)  is  used  in  the  development  effort)  The  output  of  the  compli¬ 
ance  analyzer  is  a  set  of  threat  statements  that  if  the  program  does  not  meet  the  specifica¬ 
tion,  presents  the  relationships  between  inputs  that  cause  a  deviation  to  occur. 


7.11  Pretty  Printing 


cessor. 


A  useful  documentation  capability,  pretty  printing  is  provided  by  the  ADADL  Pro- 
Ada-ASSURED,  AutoFlow-Ada,  Battlemap,  EDSA,  LDRA  Testbed,  and  TST. 
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8.  DYNAMIC  ANALYSIS 


This  section  reports  on  the  capabilities  provided  by  the  examined  tools  for  dynamic 
analysis  where  software  is  evaluated  based  on  its  behavior  during  execution.  Dynamic  anal¬ 
ysis  is  the  primary  method  for  validating  and  verifying  software.  Additionally,  it  is  the 
source  of  much  of  the  information  used  in  monitoring  testing  progress  and  software  quality. 
Traditionally  an  unstructured  and  labor-intensive  activity,  dynamic  analysis  is  a  significant 
cost  driver.  Table  8- 1  identifies  the  particular  functionality  provided  by  the  examined  tools. 

8.1  Assertion  Analysis 

An  assertion  is  a  logical  expression  specifying  a  program  state  that  must  exist,  or  a 
set  of  conditions  that  program  variables  must  satisfy,  at  a  particular  point  during  program 
execution.  Assertion  analysis  is  used  to  determine  whether  program  execution  is  proceed¬ 
ing  as  intended.  In  some  cases,  it  may  be  desirable  to  leave  assertions  permanently  in  the 
code  to  provide  a  self-checking  capability.  When  present  in  code,  even  if  commented  out, 
assertions  can  provide  valuable  documentation  of  intent 

Of  the  examined  tools,  only  LDRA  Testbed  currently  supports  dynamic  ass^on 
analysis.  Assertions  are  embedded  in  Ada  comments  and  can  be  used  to  (1)  specify  pie-  and 
post-conditions  for  a  section  of  code,  (2)  check  whether  inputs  satisfy  pie-determined  rang¬ 
es,  and  (3)  check  whetiier  loop  and  array  indices  are  within  bounds.  Should  any  assertion 
fail,  a  user-tailorable  failure  handling  routine  is  executed.  Assertion  checking  can  be 
switched  on  or  off,  allowing  assertions  to  remain  permanently  in  the  code. 

8.2  Coverage  Analysis 

Coverage  analysis  is  the  process  of  determining  whether  particular  parts  of  a  pro¬ 
gram  have  been  exercised.  Its  importance  is  illustrated  by  academic  studies  and  the  expe¬ 
rience  of  the  software  testing  industry  that  have  shown  that  the  average  testing  group  tiiat 
does  not  use  a  coverage  analyzer  exercises  only  50%  of  the  logical  program  structure.  As 
much  as  half  the  code  is  untested  and  therefore  many  errors  may  go  undetected  at  the  time 
of  release. 
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Table  8*1.  Dynamic  Analysis  Capabilities  of  Examined  Tools 
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a.  Used  with  TCAT,  TCAT-PATH,  <w  S-TCAT  to  animate  coverage  results. 

b.  Used  with  McCabe  Instnimentation  Tool  for  graphical  reporting  of  unit  covoage. 

c.  Used  with  McCabe  Instrumentation  Tool  for  graphical  rqxnting  of  design  subtree  coverage. 

F  -  Future  capability 


By  identifying  those  parts  of  a  program  that  have  not  yet  been  executed,  a  coverage 
analyzer  can  help  to  ensure  that  all  code  is  exercised,  thus  increasing  confidence  in  correct 
software  operation.  By  measuring  the  coverage  achieved  during  execution  with  particular 
set(s)  of  test  data,  these  tools  also  provide  a  quantitative  measure  of  test  completeness. 
Some  tools  also  aid  in  determining  the  test  data  needed  to  increase  the  coverage.  Although 
coverage  analyzers  do  not  directly  measure  software  correctness,  they  are  valuable  tools  for 
guiding  the  testing  process  and  monitoring  its  progress. 
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There  are  two  basic  types  of  coverage  analyzers.  Intrusive  analyzers  instrument 
code  with  special  statements,  called  probes,  that  record  the  execution  of  a  particular  struc¬ 
tural  program  element.  The  addition  of  extra  code  in  the  program  incurs  both  a  size  and  tim¬ 
ing  overhead.  The  alternative,  non-intrusive  analyzers,  requires  special  hardware  and  is  not 
addressed  in  this  report. 

8.2.1  Structural  Coverage  Analysis 

Several  levels  of  structural  test  coverage  have  been  proposed.  The  basic  levels  for 
unit  testing  are  statement,  branch,  and  path  coverage  which  require,  respectively,  each 
statement,  branch,  or  path  to  be  executed  at  least  once.  These  coverage  levels  impose 
increasingly  stringent  levels  of  testing  with  statement  coverage  being  the  weakest  and  path 
coverage  the  strongest.  Since  path  coverage  can  be  difficult  to  achieve,  various  additional 
levels  that  lie  between  branch  and  path  coverage  have  been  proposed.  The  best  known  of 
these  additional  levels  are  McCabe’s  Structured  Testing  and  Linear  Code  Sequence  and 
Jumps  (LCSAJs)  [Hennell  1976]. 

Although  unit-level  measures  can  be  applied  during  integration  and  system  testing, 
they  do  not  provide  the  additional  information  that  is  pertinent  at  these  levels.  During  inte¬ 
gration  testing,  for  example,  a  measure  of  the  extent  to  which  the  relationships  between 
calling  and  called  units  has  been  executed  is  useful.  Functional  measures  provide  a  more 
appropriate  measure  of  test  coverage  for  system  testing  (see  Section  8.2.3). 

Table  8-2  summarizes  the  structural  covo’age  analysis  features  of  the  examined 
tools.  As  shown  in  this  table,  the  examined  tools  vary  considerably  in  the  support  they  pro¬ 
vide.  The  requirements  for  a  test  driver  to  execute  the  instrumented  program  an  example  of 
one  of  these  differences.  LDRA  Testbed  and  TCMON  automatically  generate  this  test  driv¬ 
er,  as  does  TestGen  under  certain  circumstances.  The  generated  test  drivers  also  differ.  For 
example,  TCMON  provides  a  command-driven  test  driver  that  allows  the  user  to  explicitly 
control  the  handling  of  generated  trace  files.  Where  necessary,  both  LDRA  Testbed  and 
T(]MON  allow  special  actions  so  that  this  interface  can  be  omitted.  There  are  other  signif¬ 
icant  differences.  For  example,  LDRA  Testbed  provides  different  handling  of  trace  data  to 
support  host  and  target  testing.  It  also  separates  out  the  data  collected  from  a  concurrent 
program  to  allow  separate  reporting  for  each  task.  AdaTEST  provides  an  example  of  anoth¬ 
er  significant  difference  between  these  tools;  it  performs  coverage  analysis  at  test  execution 
time,  obviating  the  need  for  post-processing  of  large  trace  files. 
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8.2  J  Data  Flow  Coverage  Analysis 


Data  flow  coverage  has  been  proposed  as  another  measure  of  test  data  adequacy. 
While  the  traditional  structural  coverage  testing  approach  is  based  on  the  concept  that  all 
of  the  code  must  be  executed  to  have  confidence  in  its  conect  operation,  data  flow  testing 
is  based  on  the  concept  that  all  of  the  program  variables  must  be  exercised. 

While  there  are  several  tools  that  provide  this  capability  for  C  programs,  production 
quality  tools  for  data  flow  testing  of  Ada  code  are  not  yet  available.  The  data  flow  testing 
capability  of  LDRA  Testbed,  however,  is  currently  under  beta  testing  and  AdaTEST  is 
expected  to  provide  this  capability  in  the  near  fiiture. 


Table  &>2.  Structural  Coverage  Analysis  Characteristics 
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a.  Used  with  TCAT,  TCAT-PATH,  or  S-TCAT  to  animate  coverage  results. 

b.  Used  with  McCabe  Insmunentation  Tool  for  graphical  reporting  of  unit  coverage. 

c.  Used  with  McCabe  Instrumentation  Tool  for  graphical  reporting  of  design  subtree  coverage. 


F  -  Future  capability 

8.2  J  Functional  Coverage  Analysis 


Functional  coverage,  sometimes  called  requirements  coverage,  provides  a  measure 
of  the  extent  to  which  tests  have  caused  execution  of  the  functions  that  the  software  is 


required  to  perform.  Unlike  structural  tests,  functional  tests  can  determine  problems  such 
as  the  absence  of  needed  code. 

Two  of  the  examined  tools  assess  the  functional  coverage  of  tests.  SoftTest  provides 
a  measure  of  test  adequacy  in  terms  of  the  number  of  tested  functional  variations  with 
respect  to  the  number  of  those  testable.  T  provides  a  measure  of  test  adequacy  based  on 
requirements  coverage  using  user  specified  pass/fail  results.  An  additional  test  comprehen¬ 
siveness  measure  considers  requirements  coverage,  input  domain  coverage,  ouq)ut  range 
coverage  and,  optionally,  structural  coverage,  where  each  factor  can  be  user  weighted. 

8.3  Profiling 

Profiling  provides  a  trace  of  the  flow  of  control  during  software  execution.  This 
information  can  aid  in  locating  the  cause  of  a  failure  and  the  position  of  the  associated 
defect.  Of  the  examined  tools,  AdaTEST,  LDRA  Testbed,  and  TST  provide  this  capability 
as  an  optional  feature.  AdaTEST  allows  the  user  to  specify  the  level  of  tracing  required. 
The  user  can  request  tracing  of  unit  calls,  tracing  of  decision  calls,  or  full  tracing  at  the 
statement  level.  LDRA  Testbed  and  TST  provide  statement  level  tracing.  In  the  case  of 
LDRA  Testbed,  however,  the  Testbed  may  override  the  user  request  if  the  resulting  display 
exceeds  a  preset  limit.  SLICE  operates  in  conjunction  with  the  McCabe  Instrumentation 
Tool  and  Battlemap  to  identify,  both  textually  and  graphically,  the  particular  program  ele¬ 
ments  exercised  during  a  program  execution  in  one  or  more  program  units.  AdaTEST 
allows  the  user  to  specify  the  level  of  tracing  required.  The  user  can  request  tracing  of  unit 
calls,  tracing  of  decision  calls,  or  full  tracing  at  the  statement  level. 

In  general,  the  majority  of  computing  time  is  incurred  by  only  a  few  program  seg¬ 
ments.  This  may  be  because  these  segments  are  called  frequently,  are  computationally 
intensive,  or  both.  When  a  program  needs  to  be  optimized,  therefore,  it  is  more  efficient  to 
start  by  identifying  where  the  majority  of  computing  time  is  spent  so  that  the  optimization 
effort  can  be  appropriately  focused.  Information  on  the  number  of  times  particular  program 
segments  are  executed  can  aid  this  determination.  The  coverage  analysis  tools  all  give  the 
number  of  times  examined  program  elements  are  executed;  some  additionally  identify  the 
number  of  times  each  program  unit  is  invoked. 

8.4  Timing  Analysis 

Tuning  analysis  serves  several  purposes.  These  range  firom  supporting  the  valida¬ 
tion  of  requirements  that  impose  specific  timing  constraints  on  software  functions  to  iden¬ 
tifying  particular  program  units  that  consume  a  significant  proportion  of  computing  time. 
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AdaQuest,  AdaTEST,  and  TCMON  provide  timing  analysis.  Both  AdaQuest  and 
TCMON  offer  the  flexibility  of  user-specified  placement  of  timers,  and  measurement  using 
either  clock  or  wall  time.  TCMON  additionally  allows  a  user  to  request  automatic  timer 
instrumentation  at  the  program  unit  level.  This  tool  reports  on  the  placement  of  timers  (and 
any  counters  used  for  structural  coverage  analysis)  to  provide  information  that  can  be  used 
to  estimate  the  influence  of  instrumentation  statements  on  measured  time.  AdaTEST  pro¬ 
vides  the  user  the  capability  to  start,  stop,  and  reset  a  timer  that  c^tures  execution  time  to 
the  resolution  of  the  Ada  CALENDAR.CLOCK. 


8.5  Test  Bed  Generation 

Unit  and  integration  testing  require  the  ability  to  invoke  the  appropriate  modules, 
passing  necessary  inputs  and  capturing  the  actual  outputs  so  that  they  can  be  compared 
against  expected  outputs.  Integration  testing  may  proceed  in  either  a  top-down  or  bottom- 
up  manner.  Top-down  testing  starts  with  the  most  abstract,  or  high-level  modules,  and 
requires  the  use  of  stubs  to  represent  those  modules  called  by  the  module  under  test  In  bot- 
tom-up  testing,  the  most  detailed,  or  lower-level,  modules  are  tested  first.  Here  test  drivers 
are  required  to  simulate  the  modules  that  invoke  the  modules  under  test  Development  of 
such  test  drivers  and  stubs  can  be  complex  and  greatly  facilitated  by  automated  support.  In 
addition  to  eliminating  the  need  for  much  manual  labor,  automatic  generation  also  pro¬ 
motes  a  standardized  testing  environment 

LDRA  Testbed,  TCMON,  and  TestGen  all  generate  the  test  drivers  needed  for  exe¬ 
cution  of  an  instrumented  program.  These  are,  however,  very  limited  drivers  primarily 
intended  to  handle  the  trace  files  used  to  collect  coverage  details.  Of  the  examined  tools, 
AdaTEST,  TBGEN,  and  TST  are  the  only  ones  that  provide  test  control  via  some  form  of 
conunand  language,  and  only  AdaTEST  and  TBGEN  support  stub  generation.  Table  8-3 
summarizes  the  test  bed  generation  characteristics  of  these  three  tools. 

8.6  Test  Data  Generation  Support 

Dynamic  analysis  requires  software  to  be  executed  with  a  set  of  test  data.  The 
resulting  outputs  are  then  captured  and  compared  with  the  outputs  expected  for  the  given 
input  data.  The  traditionally  manual  and  labor-intensive  mefliod  of  preparing  test  data  has 
typically  limited  the  extent  of  testing.  Although  the  available  tools  do  not  totally  replace 
the  human  effort  required,  they  can  make  a  substantial  reduction  to  the  amount  of  human 
labor  needed. 
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Table  8-3.  Test  Bed  Generation  Characteristics 


TOOL  NAME 

Driver  GeneratioB  | 

Stub  Generation  | 

Interactive  Operation  | 

Script-based  Operation  | 

Control  Included  Entities  | 

Support  Ibbie-driven  Test  | 

Command  Language 

Record 

Keeping 

Variable  Checks 

Call  Checks 

External  Event  Checks 

Exception  Checks 

Timer  Checks 

Test  Bed  Variables 

Control  Constructs 

Breaks 

Execution  Log 

1 

§ 

Execution  Statistics 

User  Input  Recording 

TBGEN 

u 

u 

u 

u 

u 

u 

u 

■ 

u 

u 

u 

El 

El 

El 

El 

TST 

a 

u 

El 

1 

m 

m 

m 

m 

11 

m 

11 

m 

EM 

11 

li 

EM 

EM 

li 

■ 

As  mentioned  above,  dynamic  analysis  requires  comparing  expected  results  against 
actual  results  to  determine  the  success  or  failure  of  a  test  Determining  expected  results  is 
another  traditionally  manual  and  difficult  task.  Research  into  tools,  called  oracles,  to  auto¬ 
mate  this  task  has  been  ongoing  for  many  years.  As  yet,  however,  symbolic  evaluators  (see 
Section  7.9)  come  the  closest  to  supporting  this  capability. 

8.6.1  Structural  Test  Data  Generation 

During  testing,  there  are  occasions  where  it  is  necessary  to  determine  the  test  data 
that  will  cause  a  specific  branch  or  path  to  be  executed.  This  occurs,  for  example,  when  it 
is  necessary  to  attain  a  specified  level  of  structural  coverage  and  existing  test  data  has  not 
executed  some  structural  elements. 

Support  for  this  activity  is  available  at  two  levels.  AdaC^est  and  TCAT  explicitly 
identify  the  program  segments  that  comprise  particular  program  branches  and  paths.  LDRA 
Testbed,  Logiscope,  TCAT-PATH,  and  TestGen  provide  the  same  information  and,  addi¬ 
tionally,  explicitly  identify  the  conditions  required  to  cause  each  structural  element  to  be 
executed. 

8.6.2  Functional  Test  Data  Generation 

Functional  tests  can  be  derived  from  a  requirements  specification  using  three  cate¬ 
gories  of  methods:  (1)  algorithmic  techniques  such  as  cause-effect  graphing,  equivalence 
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class  partitioning,  and  boundary  value  analysis;  (2)  heuristic  techniques  including  fault 
directed  testing  and  the  traditional  error  guessing;  and  (3)  random  techniques  that  employ 
random  generation  of  test  data. 

T  supports  all  these  techniques.  Additionally,  it  is  capable  of  incremental  test  data 
generation,  that  is,  tests  can  be  generated  for  software  changes  only.  T  is  the  only  examined 
tool  that  produces  test  data  values  ready  for  iiiunediate  use  in  testing. 

SoftTest  supports  cause-effect  graphing  to  con^ile  a  database  of  input  conditions 
for  each  unique  function.  The  user  then  works  from  these  conditions  to  determine  die  nec¬ 
essary  test  data.  In  those  cases  where  identified  functions  are  not  directly  testable,  for  exam¬ 
ple,  because  results  produced  by  one  function  may  be  obscured  by  other  functions,  SoftTest 
identifies  intermediate  results  that,  if  observable,  would  enable  otherwise  obscured  func¬ 
tions  to  be  tested. 

8.6  J  Parameter  Test  Data  Generation 

Thorough  test  coverage  at  the  integration  level  requires  diat  each  subprogram  be 
executed  over  a  range  of  parameter  values.  Of  the  examined  tools,  only  TST  provides  auto¬ 
mated  generation  of  test  data  for  certain  types  of  subprogram  parameters.  This  generation 
occurs  in  one  of  two  forms.  The  user  can  specify  that  all  possible  values  for  a  parameter  be 
generated  (or  first  and  last  values  for  floating  point  numbers).  Alternatively,  the  user  can 
request  that  these  values  are  divided  into  a  number  of  partitions  and  that  the  first,  middle, 
and  last  values  from  each  partition  be  selected. 

8.6.4  Grammar>based  Test  Data  Generation 

In  those  cases  when  the  test  data  is  simply  structured,  and  this  structure  is  amenable 
to  description,  grammar-based  test  data  generation  allows  rapid,  automated  generation  of 
large  amounts  of  test  data.  This  capabiliQr  is  particularly  useful  in  random  testing. 

TDGen  provides  this  functionality.  Test  data  is  generated  according  to  location-spe¬ 
cific  data,  uniformly  distributed  data,  or  value-factored  data.  TDGen  can  generate  data  ran¬ 
domly,  sequentially,  or  according  to  a  user  specification. 

8.7  Test  Data  Analysis 

Two  types  of  test  data  analysis  are  considoed  here.  In  the  first  case,  test  data  sets 
are  analyzed  to  identify  which  test  data  sets  execute  which  lines  of  code.  When  particular 
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lines  of  code  are  changed,  this  information  shows  which  test  data  sets  are  affected  by  the 
change  and  must  be  rerun.  The  second  type  of  test  data  analysis  detects  and  reports  on 
redundant  test  data  sets.  This  identifies  test  data  sets  that  are  essentially  equivalent  in  effect 
and,  therefore,  can  be  eliminated  to  reduce  testing  cost  without  aff^ecting  test  eff^ectiveness. 

LDRA  Testbed  is  the  only  identified  tool  that  supports  these  capabilities.  The  anal¬ 
yses  are  performed  on  data  collected  during  structural  coverage  analysis. 


8.8  Dynamic  Graph  Generation 


A  visual  representation  of  the  execution  flow  of  a  program  can  aid  in  understanding 
that  program  and  diagnosing  the  cause  of  failures.  ACT  provides  this  capability  at  the  unit 
level,  whereas  Battlemap,  LDRA  Testbed,  and  Logiscope  provide  it  at  both  the  unit  and 
integration  levels.  TSCOPE  uses  the  outputs  of  TCAT  or  TCAT-PATH  to  animate  the  exe¬ 
cution  coverage  on  a  directed  graph;  and  the  output  of  S-TCAT  can  be  used  to  animate  cov¬ 
erage  on  a  call  tree  representation  of  the  program  under  test  SLICE  uses  the  ouqruts  of  the 
McCabe  Instrumentation  Tool  and  Battlemap  to  highlight  the  path  taken  by  a  particular 
execution. 
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10.  INTRODUCTION 


This  part  of  the  report  describes  the  selected  tools  in  terms  of  their  usage.  Tools  are 
grouped  by  supplier  and  the  report  details  dte  operating  environment  and  the  functionality 
provided.  Where  applicable,  price  information,  accurate  at  the  time  of  examination,  is  also 
included.  Each  description  is  supported  with  observations  on  ease  of  use,  docuntentation 
and  user  support,  and  Ada  restrictions.  Problems  encountered  during  the  examinations  pro¬ 
vided  insight  into  the  reliability  and  robustness  of  each  tool.  Each  description  is  accompa¬ 
nied  by  sample  ouq)uts. 

Table  10-1  summarizes  the  details  given  for  each  tool.  It  also  identifies  available 
bridges  between  testing  tools  and  CASE  sy^ems.  Table  10-2  presents  relevant  supplier 
data. 
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Table  10-1  continued.  Tool  Profiles 


F-  Capability  under  development  M-  Menu  drive  *  -  Version  marketed  by  DDC  International 

U  -  Users  C  -  Command  driven  a  -  Price  for  3-day  training  course 

S  -  Sites  B  -  Menu  and  command  driven  b  -  Sold  as  group 

O  -  Optional 


Table  10-2 .  Supplier  Profiles 


Table  10>2  continued.  Supplier  Profiles 
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29.  Ada-ASSURED 


» 
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Ada-ASSURED  is  a  set  of  multi-window,  language-sensitive  editors  that  analyze 
the  compliance  of  code  with  the  Ada  Quality  and  Style  Guidelines  [SPC 1991]  recommend¬ 
ed  by  the  Ada  Joint  Program  Office  and  included  in  the  BMDO  Software  Standards.  Addi¬ 
tionally,  the  toolset  provides  for  program  browsing  and  program  reformatting. 

29.1  Tool  Overview 

Ada-ASSURED  was  developed  by  GrammaTech  and  Loral  Aerospace  Corpora¬ 
tion.  The  first  version  of  this  toolset,  versicm  1.0,  became  available  in  November  1992.  It 
runs  under  Unix  and  XU  Windows,  with  Motif  and  Open^K^ndows,  on  a  variety  of  com¬ 
puters  including  the  Sun  SPARCstation,  DECstation,  HP  9000,  and  IBM  RISC  System/ 
6000. 

The  evaluati<m  was  performed  on  Ada-ASSURED  version  1.0  rurming  on  a  Sun 
SPARCstation  under  Unix  with  OpenWindows.  At  the  time  of  evaluation,  the  price  for 
Ada-ASSURED  started  at  $1,495. 

Ada-ASSURED  consists  of  three  Ada  language-sensitive  editors: 

•  Ada  Editor.  Ensures  syntactic  correctness  and  consistent  source  code  format¬ 
ting. 

•  Ada  Style-Enforcement  Editcar.  Extends  the  Ada  Editor  with  compliance  check¬ 
ing  against  the  SPC  Ada  Quality  and  Style  Guidelines. 

•  ADL^  Enforcement  Editor:  Extends  the  Ada  Style-Enforcentent  Editra*  with 
language-sensitive  editing  of  ADL  and  checking  the  consistency  of  Ada  code 
with  ADL  constructs  embedded  as  comments. 


*  ADLisan  Ada  program  design  and  docoinentation  language  developed  by  the  Lond  Aerospace  Corpora- 
#  tkm. 
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The  examination  focused  on  the  style  compliance  and  browsing  functions  of  Ada- 
ASSURED,  that  is,  the  Ada  Style-Enforcement  Editor.  Its  capability  as  a  language-sensi¬ 
tive  editor  was  not  examined,  neither  was  its  support  for  ADL. 

The  Ada  Style-Enforcement  Editor  manipulates  objects  that  are  structured  accord¬ 
ing  to  the  grammatical  rules  of  a  particular  language.  The  editor  contains  grammatical  rules 
for  several  different  languages  including  Ada  and  the  language  of  hypertext  cards.  Each 
object  is  typed  according  to  its  linguistic  category,  called  a  phylum.  The  editor  enforces  the 
grammatical  rules  that  describe  permissible  combinations  of  objects  for  the  relevant  phy¬ 
lum.  Objects  are  browsed  and  edited  in  buffers,  each  associated  with  a  particular  phylum. 
Buffos  themselves  are  associated  with  external  files  which  may  be  files  being  edited  or 
defined  buffers  that  provide,  for  example,  editing  templates.  Objects  consist  of  phrases  and 
while  the  structure  contained  in  a  buffer  is  a  syntactically  well-formed  object  of  the  phy¬ 
lum,  it  may  contain  phrases  of  unparsed  text  known  as  text  hirers.  It  may  also  contain 
placeholders,  that  is,  phrases  that  describe  the  phylum  permitted  or  required  at  a  given  posi¬ 
tion. 

Buffers  are  presented  in  textual  views  where  each  view  is  associated  with  a  distinct 
collection  of  pretty  printing  rules.  Views  may  differ  radically,  for  example,  including  or 
excluding  in-line  error  messages.  Possible  views  include  the  following: 

•  Baseview.  This  is  the  default  view  and  it  contains  a  view  of  the  object  as  defined 
in  the  enforcement  parameters.  Errors  can  appear  in-line. 

•  Ada  only.  This  is  a  view  of  the  obj«;t  as  an  Ada  program  with  no  style  enforce¬ 
ment 

•  Ada  enforcement  errors.  This  is  a  view  containing  enforcement  error  messages 
and  terms  that  ate  considered  placeholders. 

•  Ada-only  errors.  A  view  that  displays  errors  detected  in  the  Ada  and  placeholder 
terms. 

•  Ada  enforcement  indicators.  Displays  the  enforcement  parameters  that  are  in 
effect  erforcement  indicators,  error  messages,  and  placeholder  terms. 

Within  a  view,  each  phrase  has  a  ^nincipal  and  other  optional  pretty  printing 
schemes  which  govern  how  that  phrase  is  displayed.  Alternate  pretty  printing  schemes 
allow,  for  example,  elison  where  a  phrase  is  displayed  as  “  ...  ”  and  its  detailed  text  is  hid¬ 
den. 
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A  standard  window  has  the  typical  title  bar  and  menu  bar.  It  also  contains  a  message 
pane  that  presents  error  and  advisoiy  messages,  an  object  pane  displaying  the  object  con¬ 
tained  in  a  buffer,  and  context  pane  displaying  context-sensitive  status  information  and 
commands.  Windows  can  be  switched  between  views  and  buffers,  and  they  can  be  dupli¬ 
cated  and  deleted. 

Traditional  window-type  navigation  such  as  using  the  insertion  cursor,  a  locator 
such  as  a  mouse,  and  scrolling  are  supported.  Each  object  has  a  structural  selection  that 
identifies  the  current  focus  of  structural  edit  opoations  and  Ada- ASSURED  also  provides 
for  navigation  with  structural  selection.  (Each  buffer  has  only  c>ne  structural  selection 
regardless  of  the  number  of  windows,  the  structural  selection  is  updated  in  all  windows  dis¬ 
playing  the  buffer.)  In  this  last  type  of  navigation,  the  currently  selected  structure  in  the 
buffer  can  be  moved  relative  to  its  current  location  using  various  treewalking  regimes,  for 
example,  preorder,  reverse  preorder,  ascend-to-parent,  forward-sibling,  and  struct-select- 
to-top.  These  can  be  used  to  quickly  find,  for  example,  the  next  item  in  list  All  commands 
that  move  the  structural  selection  are  parser-initiating.  This  means  that  text  is  (re)parsed  if 
the  text  buffer  has  been  modified  since  the  last  attempt  to  parse  it,  the  target  location  is 
beyond  the  end  of  the  text  buffer,  auto-parsing  mode  is  enabled,  or  the  current  structural 
selection  is  a  text  buffer. 

Parsing  establishes  the  syntactic  correctness  of  text  buffers.  As  just  mentioned,  it 
can  be  invoked  automatically  by  parsing-initiating  commands  when  the  auto-parsing  mode 
is  enabled,  or  it  can  be  invoked  tiumually.  In  addition  to  ensuring  conformance  to  Ada  syn¬ 
tax,  parsing  causes  the  Ada  Style-EnforceiiKnt  Editor  to  analyze  Ada  code  with  respect  to 
the  SPC  Ada  Quality  and  Style  Guidelines.  The  automatic  formatting  provided  by  the  lan¬ 
guage-sensitive  editor  means  that  some  of  these  guidelines  are  automatically  enforced; 
including,  for  example,  horizontal  spacing  and  indentation.  Otherwise,  the  user  can  set 
enforcement  parameters  to  enable  or  disable  the  enforcement  of  individual  style  guidelines. 
When  a  parameter  is  changed,  the  user  can  choose  to  apply  it  inunediately  to  the  current 
buffer. 

Ada- ASSURED  provides  two  levels  of  enforcement:  indicators  and  errors.  In  gen¬ 
eral,  indicators  are  used  to  signify  guideline  violations  that  are  not  considered  critical;  they 
can  be  treated  as  warnings  and  only  appear  in  a  special  indicator  view.  Errors,  on  the  other 
hand,  denote  more  serious  guideline  violations  that  should  not  be  ignored  and  they  shown 
within  the  code  as  in-line  error  messages  contained  in  comments.  In  some  cases,  when  a 


guideline  is  violated,  Ada-ASSURED  offers  an  automatic  transformation  to  bring  the  code 
into  compliance. 

A  script  interpreter  provides  the  ability  to  invoke  Ada-ASSURED  editors,  either 
interactively  or  in  batch  mode,  with  a  script  of  commands.  This  capability  allows  the  user 
to  provide  new  compound  editing  actions  that  extend  the  functionality  of  the  editor,  to 
invoke  an  initialization  script  on  start  up  to  customize  editor  operation,  and  to  define  their 
own  templates  which  can  be  used  to  replace  appropriate  placeholders.  It  also  allows  editors 
to  serve  as  batch  tools  such  as  pretty  printers  and  int>gTam  analyzers.  (An  editor  running  in 
batch  mode  does  not  start  up  any  windows,  the  result  of  interpreting  a  script  is  printed  to  a 
special  buffer  *transcript*.)  Scripts  are  written  in  a  language  called  Dynamic  SSL  and  con¬ 
sist  of  function  definitions  that  may  involK  built-in  library  functions  and  commands.  INT, 
REAL,  BOOL,  CHAR,  and  TOK  are  provided  as  primitive  phyla  and  all  editing  functions 
are  available  as  built-in  primitive  functions.  A  special  script  editor  with  a  complete  set  of 
parsing  rules  and  transformations  is  available  to  support  their  creation  and  maintenance. 
This  editor  also  provides  special  commands  that  allow  scripts  to  be  inteixnreted  from  within 
the  editor. 

29.2  Observations 

Ease  of  use.  Ada-ASSURED  uses  on-line  hypertext  to  provide  context-sensitive 
help  and  a  cross-reference  to  the  Ada  Language  Reference  Manual.  Additional  aid  for  the 
user  is  provided  through  facilities  such  as  a  file-and-directory  browser  that  can  be  used  with 
commands  that  read  and  write  files  to  assist  in  locating  file  names  of  interest 

The  hypertext  help  can  be  extended  by  preparing  additional  hypertext  cards  and 
linking  them  into  the  basic  hypertext  web.  The  standard  X  resource  interface  can  be  cus¬ 
tomized  to  affect,  for  example,  key  bindings  and  type  face.  Menus  are  available  to  adjust 
window  layout  and  features  such  as  wordwrap.  There  are  several  levels  of  customization 
available  for  the  editors.  Editor  style  can  be  adjusted,  for  example,  via  the  style  templates 
associated  with  each  editor.  Style  is  defined  in  terms  of  font,  size,  slant,  weight,  and  color. 
Styles  are  derived  by  successively  applying  templates  to  the  default  style,  itself  generated 
by  applying  the  default  template  to  a  wot  style  that  is  generated  when  the  editor  is  invoked. 
The  following  styles  are  provided  with  Ada-ASSURED  and  can  be  customized;  Back¬ 
ground,  Comment,  Enx>r,  Indicator,  Keyword,  and  Placeholder.  Dynamic  SSL  provides 
another  method  for  customizing  an  editor  through  interpreted  scripts.  Alternatively,  the 
user  can  exploit  the  fact  that  Ada-ASSURED  is  itself  generated  by  GrammaTech’s  Synthe- 
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sizer  Generator  from  a  high-level,  rule-based  description.  By  modifying  this  description  the 
language-sensitive  editor  generator  allows  rapid  production  of  a  customized  editor. 

Documentation  and  user  support.  A  reference  manual  is  available  on-line  as  a 
web  of  hypertext  cards.  An  on-line  tutorial  is  provided  that  uses  these  cards. 

Ada  restrictions.  None. 

Problems  encountered.  The  only  problem  encountered  was  in  running  one  of  the 
sample  Dynamic  SSL  scripts  that  were  provided.  This  script  contained  an  error  that  needed 
ccnrection.  Otherwise,  Ada- ASSURED  performed  as  described  in  the  documentation. 

29.3  Planned  Additions 

Subsequent  to  this  review,  GrammaTech  have  released  Ada- ASSURED  version  1.2 
This  new  version  provides  facilities  for  integration  with  any  compiler.  Future  versions  of 
Ada- ASSURED  will  provide  the  capability  for  semantic  browsing  and  integration  with  tool 
managers. 

29.4  Sample  Outputs 

Figures  29-1  through  29-6  provide  sample  ouq>uts  from  Ada- ASSURED. 
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Figure  29-2.  Ada-ASSURED  Navigation  by  StnicturaJ  S  lection 
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Figure  29-4.  Ada-ASSURED  Enforcement  Indicators 
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Figure  29-6.  Ada-ASSURED  Automatic  Error  Correction 


30.  AdaTEST 
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AdaTEST  ccmsists  of  three  ctMnptments:  the  AdaTEST  Harness  (ATH),  the  AdaT¬ 
EST  Analyser  (ATA),  and  the  AdaTEST  Instnunentm-  (ATI).  It  supp(»ts  unit  testing  and 
bottom-up  testing  of  Ada  code.  ATH  is  a  library  of  Ada  packages  that  provide  facilities  to 
write  a  test  script  that  supports  white  box  testing  of  Ada  program  units.  It  passes  data  to  die 
unit  under  test  and  allows  the  user  to  check  the  results  of  the  unit,  including  the  correct 
prqiagation  of  excqitions.  ATH  also  supports  simulating  the  interaction  between  the  unit 
under  test  and  other  (perhtqis  undeveltqied)  units  and,  finally,  verifying  diat  run-time  per¬ 
formance  requirements  are  met  ATI  provides  static  analysis  to  calculate  code  complexity 
of  the  unit  under  test  b  also  iiutruments  the  code  to  {Hovide  statement  decision,  boolean 
expression,  exception,  and  call  coverage.  Finally,  ATA  is  anotiier  library  of  Ada  packages 
that  allows  testing  the  instrumented  unit  in  the  same  way  as  ATH  packages,  and  addition¬ 
ally  reporting  on  die  static  and  coverage  analyses.  ATA  also  supports  tracing  the  path  of 
execution  through  the  unit  under  test 

AdaTEST  was  developed  for  use  in  the  high-integrity/safety-critical  development 
arena.  Accordingly,  ATH,  the  core  of  AdaTEST,  was  developed  as  a  safety-critical  devel¬ 
opment  in  its  own  tight  using  the  same  standard  specified  fw  use  in  the  Eurojet  project 
(part  of  the  European  Fighter  Aircraft  jKoject).  The  remainder  of  AdaTEST  was  developed 
to  IPL’s  usual  development  standards,  including  ISO  19001. 

30.1  Totri  Overview 

AdaTEST  was  developed  by  Informatitm  Processing  Limited  in  Bath,  England.  IFL 
also  provide  training,  consultancy,  and  hot-line  support  to  tool  users.  They  have  recently 
established  a  relatitmship  with  a  U.S.  company,  Texel  &  Co.,  who  will  market  and  support 
AdaTEST  in  this  country.  AdaTEST  was  first  marketed  in  1991  and  is  now  used  at  more 
than  IS  sites  intemationally.  It  is  machine  and  operating  system  indepen^t,  relying  tmly 
on  the  available  Ada  compUer.  The  examination  was  performed  on  AdaTEST  Harness 
(ATH)  version  2.3,  AdaTEST  Analysis  (ATA)  version  2.1,  and  AdaTEST  Instrumentor 
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(ATI)  vcTsicm  2. 1.  Tliese  ran  on  a  Sun-3  w<»kstation  under  a  Verdix  Ada  Development  Sys¬ 
tem.  At  that  time,  the  price  for  AdaTEST  started  at  £9^00. 

30.1.1  ATH  Overview 

The  user  begins  with  AdaTEST  by  using  the  library  of  packages  that  constitute  ATH 
to  construct  a  test  script  This  test  script  will  act  as  a  main  procedure  and  invtdte  the  unit 
under  test  Consequently,  a  test  script  is  compiled  and  linked  as  a  normal  Ada  main  pro¬ 
gram,  and  changes  to  the  test  script  only  require  its  recompilation  and  the  relinking  of  the 
program;  the  software  under  test  is  unaffected. 

ATH  provides  a  number  of  directives  that  are  used  in  the  test  script  to  ccmtrol  the 
invocation  of  the  unit  under  test  and  to  check  its  results.  The  structure  of  the  test  script,  and 
placement  of  directives,  is  governed  by  two  state  machines:  the  script  state  machine  and  the 
timer  state  machine.  If  the  user  causes  a  directive  to  be  called  ^m  an  inapprc^rriate  state, 
a  script  error  is  generated  and  the  test  fails.  (A  set  of  diagnostic  error  messages  helps  the 
user  to  determine  the  c^ise  of  a  script  etm,  and  limited  error  recovery  is  ]novided  by 
adopting  the  correct  state  after  a  script  error  has  been  given.  Of  course,  side  effects  from 
the  error  may  prevent  complete  recovery.) 

The  user  is  provided  with  a  template  that  aids  in  test  script  construction.  A  test  script 
starts  by  setting  the  context  in  terms  of  witidng  and  useing  needed  packages.  Then  the  script 
is  opened  and  any  necessary  test  data  is  declared,  followed  by  the  instantiation  of  necessary 
check  procedures.  A  series  of  test  cases  specify  the  data  to  be  passed  to  the  unit  under  test, 
the  data  expected  to  be  returned  by  the  unit,  and  the  various  checks  that  should  be  made  to 
check  correct  unit  operation.  After  the  main  body  of  the  test  script  is  closed,  the  stub  section 
provides  the  definition  of  any  stubs  that  are  to  be  simulated.  The  basic  opoution  of  this  part 
of  AdaTEST  can  be  illustrated  be  loddng  at  some  of  the  major  directives  tfiat  are  used  in 
the  main  body  and  stub  section  of  a  test  script 

Basic  directives  are  used  to  declare  the  start  and  end  of  a  test  script  and  start  and 
end  of  each  individual  test  case.  Within  each  test  case,  the  EXECUTE  directive  precedes 
the  actual  invocation  of  the  unit  under  test  It  allows  the  user  to  identify  the  unit  the  expect¬ 
ed  sequence  of  stub  calls,  if  any,  made  by  the  unit  and  whether  an  exception  is  expected  to 
be  propagated.  A  comjKinion  directive  DONE  follows  the  invocation  of  fiie  unit  under  test 
and  verifies  that  the  number  of  stub  calls  and  any  exception  propagation  is  as  stated  in  the 
preceding  EXECUIE.  Next  a  series  of  checks  can  be  made  to  verify  the  test  case  outputs. 
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CHECK  is  used  to  verify  that  an  object  of  a  predefined  Ada  type  contains  the  expected  val¬ 
ue.  To  allow  more  flexibility,  ATH  also  provides  a  set  of  generic  checking  routines  that  the 
user  can  use  to  check  the  results  feu-  user-tkfiired  integer,  enumeraticMi,  floating,  and  fixed 
types  and,  with  the  exception  of  limited  private  types,  any  other  user-defiiwd  types.  A  check 
directive  for  comparing  raw  mem«y  is  also  provided.  In  addititm  to  checking  the  value  of 
data  against  expected  data,  ATH  provides  for  checking  of  events.  Here  expected  external 
physical  events  can  be  checked  by  requesting  the  operator  to  confirm  that  a  particular  event 
has  occurred.  Also  the  exceptions  propagated  by  die  unit  under  test  can  be  examined.  The 
CX)RR£CT_EXCEFTION  and  IIJLEGAL_EXCHFT10N  directives  allow  the  test  to  indi¬ 
cate  whether  an  exception  has  been  propagated  correctly,  or  unexpectedly. 

Timing  analysis  is  supported  by  special  directives  to  reset,  start,  and  stop  the  timer 
and  check  timer  results.  Since  the  processing  involved  in  stub  calls  can  have  an  effect  on 
the  execution  of  the  unit  under  test,  it  is  recommended  that  a  test  script  should  not  use  sim¬ 
ulation  when  timing  analysis  is  being  performed.  For  a  test  script  to  be  portable  between 
host  and  target  environments,  timing  checks  are  specific  to  the  environment  in  which  the 
test  is  executed.  Timing  directives  ate  ignored  in  the  host  environment  and  this  type  of  anal¬ 
ysis  is  only  performed  in  the  target  environment 

AdaTEST’s  stub  simulation  supports  testing  units  in  isolation,  where  interaction 
with  other  units  is  simulated.  (In  bottom-up  testing,  stub  simulation  can  be  used  to  replace 
those  units  not  yet  available.)  The  user  can  voify  the  order  of  calls  to  simulated  units,  and 
verify  the  values  of  in  and  in-out  parameters  passed  to  simulated  units.  The  user  is  also  pro¬ 
vided  with  further  control  in  die  test  process  by  the  ability  to  initialize  the  values  of  in-out 
and  out  parameters,  function  return  values,  and  other  data.  Hie  sequence  of  expected  calls 
to  simulated  units  is  usually  given  in  the  EXECUTE  directive  included  in  each  test  case  to 
allow  the  user  to  specify  unique  processing  for  each  separate  stub  invocation.  The  simulat¬ 
ed  unit(s)  themselves  are  defined  in  die  test  script  after  the  main  body  of  test  cases.  Again, 
special  script  directives  are  provided.  The  directives  START_STUB  and  END_STUB  are 
self-explanatory.  C  ALL_REF  is  used  to  identify  the  current  stub  reference  from  the  list  giv¬ 
en  in  EXECUTE  directive.  Since  the  Ust  of  expected  calls  in  an  EXECUTE  directive  can 
contain  loops,  the  directive  CALL_LCX!)P  is  available  to  identify  the  current  value  of  a  loop 
repetition  count  and  another  directive,  the  ILL£GAL_CALL_REF  directive,  can  be  used 
to  indicate  that  a  simulated  unit  has  been  called  out  of  sequence.  This  use  of  stub  simulation 
is  facilitated  if  all  units  in  a  system  are  declared  as  separate,  thus  obviating  the  need  to  write 
hybrid  package  bodies  containing  both  simulated  and  real  units. 
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At  the  end  of  a  test  run,  a  table  of  test  results  is  produced.  This  indicates  whether 
each  test  has  passed  or  failed  and  gives  an  overall  pass/fail  summary  of  the  test  run.  In  addi¬ 
tion,  detailed  results  are  produced.  Tests  may  be  executed  unchanged  in  both  host  and  target 
envirorunents  (with  the  exception  of  timing  arudysis,  as  stated  above).  In  a  host  environ¬ 
ment  the  detailed  test  output  generated  by  a  test  run  is  placed  in  a  results  file  for  later  exam¬ 
ination.  On  a  target,  if  no  file  system  is  available,  output  is  directed  to  the  standard  output 
device. 

Since  a  lar^e  number  of  test  cases  can  make  a  test  script  unwieldy,  ATH  supports 
table-driven  testing.  Here  the  initial  conditions  and  expected  results  for  each  test  case  are 
stored  in  a  table.  This  allows  the  test  script  to  simply  loop,  pulling  the  needed  data  for  each 
test  case  from  the  table.  Of  course,  although  the  table  can  be  extended  to  allow  for  different 
sequences  of  stub  calls  and  different  handling  of  exceptions,  this  approach  assumes  a  large 
degree  of  commonality  in  the  processing  requited  for  each  test  case.  However,  in  those  cas¬ 
es  where  a  target  system  has  limited  memory  resources,  table-driven  testing  does  allow 
reducing  the  size  of  the  executable  program. 

Tasks  are  tested  in  much  the  same  way  as  sequential  units.  While  sequential  units 
are  implicitly  synchronized  because  they  are  executed  from  within  the  EXECUTE-DONE 
block,  tasks  may  run  concurrently  with  the  test  harness.  If  a  task  has  entry  points,  then  the 
entry  point  is  called  after  the  EXECUTE  and  a  delay  statement  precedes  the  DONE  to  allow 
time  for  the  task  to  call  any  stubs  and  update  any  global  data.  If  it  is  not  possible  to  syn¬ 
chronize  the  task  using  an  entry  point,  or  the  entry  point  occurs  too  late  (for  example,  after 
a  stub  has  been  called),  special  action  is  called  fmr.  In  this  case,  the  CONCURRENT  mode 
of  ATH  must  be  used.  In  this  mode,  directives  are  locked  so  that  only  one  may  execute  at  a 
time  and  stubs  are  executed  sequentially.  Essentially,  ATH  synchnmizes  START_STUB 
with  EXECUTE  so  that  stub  calls  made  by  the  unit  under  test  will  not  proceed  until  the  test 
script  is  within  the  EXECUTE-DONE  block.  Again,  a  delay  statement  may  be  necessary. 
Similarly  END_STUB  is  synchronized  with  DONE.  After  DONE  has  executed,  any  subse¬ 
quent  stub  calls  are  suspended  until  the  next  EXECUTE.  Some  woritarounds  are  provided 
for  cases  such  as  a  task  reading  global  data  before  waiting  on  a  task  entry  or  calling  a  stub. 

CONCJURRENT  mode  is  also  required  for  multiple  tasks  and,  although  this  is  not 
stated  in  the  manual,  for  coverage  arudysis  of  a  task.  The  ATH  tasking  mode  (SEQUEN¬ 
TIAL  or  CONCTURRENT)  is  determined  when  the  test  script  and  software  under  test  are 
linked  to  form  an  executable  image.  The  marmer  of  setting  the  mode  is  dependent  on  the 
compilation  envirorunent.  Since  the  CONCURRENT  mode  is  intrusive,  it  may  affect  the 
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tuning  and  ordering  of  events  that  occur  across  multiple  tasks;  this  may  result  in  deadlocks 
where  the  program  hangs. 

30.1JI  ATI  Overview 

Unlike  ATH  and  ATA,  ATI  is  an  executable  program.  As  such  it  offers  a  command 
line  interface  for  instrumenting  subprogram  bodies,  task  bodies,  and  subunits  when  they 
appear  as  library  units  or  in  the  declaration  part  of  other  units  of  nested  block  statements. 
(Code  embedded  in  a  package  body  is  not  instrumented.)  Instrumentation  is  performed  on 
a  single  file  at  a  time. 

The  command  line  interface  offers  a  number  of  options  that  allow,  for  example,  lim¬ 
iting  the  types  of  coverage  that  the  unit  is  instrumented  for,  switching  off  task  body  instru¬ 
mentation,  and  requesting  static  analysis  results  to  be  produced  in  a  machine-readable, 
comma-separated  variable  format  suitable  for  processing  by  third-party  products  such  as 
spreadsheet  packages.  It  is  also  possible  to  limit  the  instrumentation  performed  to,  for 
example,  a  maximum  number  of  coverage  points,  or  the  maximum  limit  for  the  number  of 
bytes  used  to  store  package  and  program  unit  names.  By  default,  the  subject  file  is  instru¬ 
mented  for  all  coverage  types,  that  is,  statement,  decision,  boolean  expression,  exception, 
and  caU  coverage. 

Two  files  are  produced.  One  of  these  includes  the  mstrumented  source  code,  which 
is  ready  to  be  compiled  in  the  usual  way.  The  second  file  contains  an  annotated  listing  of 
the  source  code  and  the  results  of  the  static  analysis.  Static  metrics  are  calculated  on  a  per- 
unit  basis.  They  include  single  counting  metrics  such  as  the  total  number  of  Ada  source 
code  lines,  the  total  number  of  dynamic  stack  allocations  within  a  unit,  and  the  total  number 
of  for  loops.  Complexity  metrics  include  Halstead  metrics,  and  Hansens ’s  Cyclomatic 
number  and  operator  counts  which  are  modifications  of  McCabe’s  and  Myers’  complexity 
metrics. 

30.U  ATA  Overview 

After  it  has  been  instrumented,  a  program  unit  is  ready  for  coverage  analysis.  The 
user  converts  the  ATH  test  script  used  for  testing  the  program  unit  into  an  ATA  test  script 
by  including  ATA  directives  that  cause  the  capture,  checking,  and  reporting  of  coverage 
analysis  data.  The  initial  ATA  directive  used  is  one  to  initialize  the  analysis,  then  the  test 
cases  are  surrounded  by  directives  to  start  and  stop  coverage  analysis.  A  CHECK_ANAI^ 


47 


YSIS  directive  is  used  to  check  that,  for  a  given  unit,  a  particular  coverage  metric  or  static 
metric  lies  within  a  specified  range.  Alternatively,  the  user  can  use  the  GET  ANALYSIS 
directive  to  yield  the  value  of  a  particular  metric  and  this  data  can  be  used  in,  for  example, 
the  calculation  of  user-defined  metrics.  CHECK  CALLS  checks  that  all  members  of  a  giv¬ 
en  list  of  units  have  been  executed.  The  directives  REPORT  UNTT  and  REPORT  ANAL- 
YSIS  allow  writing  the  results  of  static  arudysis  to  the  results  file  either  unit  by  unit  or 
metric  by  metric.  A  trace  directive  is  provided  to  allow  the  user  to  request  tracing  at  either 
the  unit,  decision,  or  statement  level. 

START_SQlIPT_IMPORT  and  END_SCRIPT_EXPORT  arc  the  most  important 
of  the  remaining  directives.  These  are  used  as  alternatives  to  the  usual  START_SCRIPT 
and  END_SCRIPT  to  enable  cumulative  coverage  reporting.  As  its  name  suggests, 
START  SCRIPT  IMPORT  imports  analysis  data  and  pass/fail  results  exported  from  a  pre¬ 
vious  run,  new  results  are  then  appended  to  this  data  and  then,  using  END  SCRIPT  EX- 
PORT,  can  be  exported  to  a  set  of  files  for  later  import  by  another  test  script 

Once  the  ATA  test  script  is  prepared,  all  relevant  code  is  compiled  and  linked  as 
usual.  (As  before,  any  changes  to  the  test  script  only  require  recompiling  the  script  itself 
and  relinking  the  program.)  When  the  resulting  program  is  run,  results  of  the  analysis  and 
tracing  are  integrated  with  ATH  test  results  to  produce  an  overall  ATH/ATA  test  pass/fail. 
A  summary  of  the  pass/fail  results  is  wnrittoi  to  the  screen,  while  the  full  analysis  and,  if 
requested,  trace  results  are  written  to  the  resulv;>  file. 

ATA  operates  in  one  of  two  modes,  either  ANALYSIS  or  NON  ANALYSIS.  In  the 
ANALYSIS  mode,  ATA  operates  as  described  above..  Otherwise  ATA  ignores  all  directives 
except  the  START_SCRIPT_IMPORT  and  END_SCRIPT_EXPORT;  it  will  not  permit  the 
execution  of  instrumented  code  in  this  mode.  This  is  intended  to  allow  the  use  of  die  same 
test  script  for  both  host  and  target  machine  testing.  It  also  allows  timing  analysis  to  be 
restricted  from  being  performed  on  instrumented  code. 

30.2  Observations 

Ease  of  use.  For  ATH  and  ATA,  knowledge  of  Ada  is  all  that  is  required.  ATI  uses 
a  simple  command-line  interface  that  is  easy  to  use. 

Documentation  and  user  support.  The  documentation  as  provided  was  clear  and 
easy  to  follow.  However,  it  serves  as  a  reference  manual  rather  than  a  user  guide  and  addi¬ 
tional  examples  would  be  helpful.  IPL  provided  excellent  support,  answering  all  questions 
quickly  and  fully. 


i 


i 
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Instrumentation  overhead.  The  majority  of  the  coverage  analyzers  examined  in 
the  course  of  this  work  are  intended  for  instrumentation  of  entire  programs,  or  significant 
portions  of  a  program.  ATA  differs  in  that  it  is  primarily  intended  to  monitor  the  coverage 
achieved  in  testing  a  single  program  unit  or,  with  appropriate  use  of  test  histories,  those  pro¬ 
gram  units  examined  to  date  in  the  course  of  bottom-up  testing.  Consequently,  the  follow¬ 
ing  figures  should  not  be  directly  compared  with  those  given  for  other  coverage  analysis 
tools. 

For  the  function  LLFIND,  instrumentation  for  boolean  expression,  decision,  state¬ 
ment,  and  exception  coverage  gave  an  increase  in  the  size  of  source  code  from  810  to  4,924 
blocks.  For  package  BUFFER_INPUT_MSGS,  containing  the  BUFFER  task,  instrumenta¬ 
tion  gave  an  increase  from  2,118  to  10,811  blocks  of  source  code. 

Ada  restrictions.  AdaTEST  supports  full  Ada.  However,  ATA  does  not  instrument 
boolean  expressions  that  contain  a  relational  operator  with  one  or  more  operands  that  are 
also  boolean  expressions. 

Problems  encountered.  No  problems  were  encountered  during  use  of  AdaTEST. 
It  operated  exactly  as  described  in  the  manual. 

30  J  Planned  Additions 

IFL  is  working  on  extending  AdaTEST  to  support  data  flow  testing.  IPL  is  also 
working  on  links  to  two  major  CASE  tools  which  will  allow  automatic  test  script  genera¬ 
tion  from  the  case  design  level. 

30.4  Sample  Outputs 

Figures  30-1  through  30-13  provide  sample  ouq}uts  from  AdaTEST  on  the  Lexical 
Analyzer  Generator  example,  and  Figures  30-14  through  30-23  provide  sample  ouq>uts  for 
the  Real-Hme  Temperature  Monitor  example. 
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Mpant*  (LLriaDjnar^Mca) 

(unccioo  urxKX  rm.-  usnawaa,-  maai:  LLsms  >  neun  iMnom  !■ 
--  Find  itaa  In  aynbol  tnbln  *■  tntuxB  iadan  or  0  it  not  found. 

--  AanuMO  nyabol  tablo  la  aortod  la  aaoaadlag  ordar. 

UM,  MZOFOm.  HIOR:  lIRMn: 
bagla 

UM  ;•  li 

■nOB  :•  LUIMLBSin  *  li 
ohlla  UW  /■  aZOI  loop 

MIOFOIBT  :•  <KI<W  *  UM)  /  2) 

If  im  <  UisnBOLTMLBdapFom)  .nr  tim 

HldH  :•  KtOtOXdri 

olaif  inM  •  LLsnaoLTUumoFonir)  .nr  than 
if  LunaoucMUdOBFonm  .Km  •  much  than 
rotun<  lODFOm  )i 

alaa 

ratlin)  0  )  i 
and  If; 

alaa  --  iTBt  >  uatmoL'ZMBUfMZDrozrr)  .OT 
urn  Kotom  «  li 
and  Ifi 
•nd  loop; 

rotund  0  );  *■  ItM  io  not  in  tnblo 

•nd  Umo; 

Figure  30- 1 .  AdaTEST  Listing  of  Function  LLFIND 


«ieh  Ua^MCLMuiTZom.  mt.xoi 
paokmg*  Xit«nXIB.TUT_MO  is 
U««  XA.naCLMUtfXOM,  tSKT.SO; 

cyp*  XXOnffABSmy  is  --  tat  mvmbax  osbls  sBCriss 

RR:  idurtimasi  ••  lltaral  atring  or  group  Idaatlflar 
KxaD:  usm*t  "  litoral  or  group 
•nd  rooordi 

iiainarii  raan  amy  <  i  ..  unaauuiaa  >  oc  uimnnBamnri 
•  •  tha  ayoPol  tabla  for  lltaral  tooM 

funotloo  urm  (  ITCM:  UdTnmSt  WXCH:  udma  >  ratuxn  URlUWi 
prooadura  nsaDOmiii 


paekaga  body  LbFmjntT.PMI  la 

funetioB  udOD  )  xmi>  ixsTunMt  anzcHi  uamd  )  ratum  ipmou  ib 

aaparatoi 

prooadura  WnCJUl  ia  ••  raad  griMrr  froa  dlak 
CM:  aoutacmi 

unuuii  FXUjrvPBi  --  nOara  grmar  la  atosad 
tianin  ••  ■■MMBMI 

OPBK  l&omhf  zn.rxLs,  rnnu*  >> 

•  -  rssd  in  syobol  tsblss 

for  z  in  2  . .  iibmazMzds  loop 

for  J  in  2  . .  XXtmzMMmi  loop 

mrt  xxoHMi.  iHTiaoTygMBinti)  .cttw)  }$ 
sod  loop; 

OPTt  IfMMM.  W  )  ; 

•KZP^lfZai  (  MrtWOf  I  ; 
if  Ol  »  'V'  «>MO 

LUTOMlAMLBtZ)  rKOP 
slos  •*  SSSUM  oh  •  1 

LlgfZIMOUMMd)  ,KXm  «•  UTSUMi; 

•nd  if I 
snd  loop/ 
cLOflif  u/njm  1 1 
on4  MUMMMi 


Figure  30-2.  AdaTEST  Making  LLFIND  into  a  Separate  Unit 
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--  with  Ma(Mai_aBiK.nsT: 
with  LLmiD.TIST.m; 
uM  luxnjtEsrtjnat 

••  with  any  Rstarnnead  Paekagaa: 
with  iL_McuMaima; 
usa  LLjatajamaa; 

-•  Taat  acript  xaqulraa  tha  uaa  of  tba  KKJXMMUM  paekaga: 

with  ADKRSTjauanafl.ooMaaDS  i 

usa  JuiansT.iiMaus.aaMwns 

with  MUOIST  RMaBSS_TZIfIID_jani.YtZa  : 

uaa  huassrliiMMPSSjniinajanursia  : 

--  Taat  acript  nay  raqulra  tha  uaa  of  othar  ASH  paekagaa,  a.g  : 
--  with  MamsT  nMUs.oBmc.cBcics  : 

••  usa  JUUaBSTlaMOBUa.anBaiC.CBKKS  : 


opn  souPT 


pcoeaduxa  nST_U,PI»  is 

..  laataatlations  of  Oaiiarlc_Chaeks  if  nsadad: 

typa  LLsma  la  (LmkaL,  aupiUMijua.,  opoop,  Acnan.  patoii 

••  Daelara  work  warlablaa  if  aaadad: 
imt  ;  lASTUnaS; 
wucai  :  UltRUi 
nsoLT  :  nranut; 

baglB 

teoKtjsaart  (  •Tm8T_i*piK»*  »  ; 

•  •  Road  in  tha  taUa  to  initialisa  UsnaoutAPIik 
AlADQWgi; 


Tlasr  rasat  haxa  for  tlalng  aaalyais  latar  ’--at  script 
IIUIT_TX«  ; 


TUT  PAIHS  (Rapoat  as  ssquirsd) 
TUT  CAU  1 


START.TUT  (  1  )  ; 

-•  OOMUrr  (  •im  ■>  t.  ist  itaai  in  tabla*  )  > 

-•  CVUURT  (  •IRICH  »  1*  )  I 
--  (?n—PT  (  'RPSaLT  ■>  X*  )  I 

■o  initial  waluas  to  aat 

Zntroduos  call  to  OBlt_uadsr_Ttst  with  Call_Xdae  and  Is_laosptiea_Bvaetad: 


Figure  30*3.  ATH  Test  Script  for  Testing  LLFIND  with  Timing  Analysis 


niCTO  (  •LUI»_'nsT_»R3.U.raB>*.  **,  BCCIVTXON_IK)T_BC»ICRO  I  ; 


bagln 

STMtT.Tim  ! 

•  Malta  eall  to  aBlt_uBdar_Taat  >lth  avpropriato  valuala)  (ox  In  paraaatara 

•  and  «ork  itariabloa  (or  Out  paranatara  and  roturaad  valuoa: 

Utavt  :•  LLPlKlIZnM  ->  ■(  •,  HKICM  »  UnBM.)  ; 

•T0P_TI1«  I 


•  ■  moaptloo  handlar(a) : 

OMaptloa 

--  It  taat  oaaa  xoquizoa,  provida  a  Coxraet_lxeoptian  handlax,  a.p. 

•  •  uban  piia(MM_aM«_TiPT.>sMcns_tsamoM  •> 

COMMCT_lXCimOM  CMatPClMDJtXCtPTIOM* )  ; 

--  Aluaya  provida  an  XUMaitl<_BXCIprxCM  haadlar  (or  at  loaat  'othora'  : 
ahan  othora  •* 

lUMAL.nCBPnoM  (  •Othora’  )  ; 


and  I 

pan  ; 

Chaek  tha  raaulta  ot  oaacuting  tha  Dhit_undar_toat : 
cnac  (  •usour*,  pisolt,  i) 

OBCXjrxm  (•aoMsjoMZx*,  o.oo,  o.osi 


nsr  can  a 


STMCr.nST  (  2  )  ; 

(  ‘xm  •>  ),  Xaat  itan  in  tahla'  ) 

(  •Wiai  ■>  X*  )  ; 

•  •  oanm  (  'naiiLT  ■>  xa*  i  ; 

■nom  (  •ixranjxmsT.PBa.Li.pm*,  ••,  axctmoK 


bogln 

RUai.T  :■  lUXMDdTBl  ■>  •) 
axeaption 
ahan  etbmxm  •> 

iuMa(._ncimaM  c  •othara*  > 
and  ; 


)  t 

• ,  MMiCH  a>  Lnntax.)  i 


CBKT  (  •RBSOUT',  B£fOLT,  »)  > 


TUT  can  1 


araKr.Tnr  (  x  i 

(  *ITai  «>  Charldt,  aon 
(  ’auca  •>  oRoop*  i 
(  •anoiA'  •>  ix*  )  , 
nicon  (  'luiPD.TUT.iiai.xdraD',  ••, 

RHOIT  &LraB(XtBf  •>  •CharUt 
axoaptlon 
ahan  othara  a> 

XIUOaL.IXCimaH  <  •othara*  >  ; 


»try’  )  ; 

nai>TioM_MOT_muc'xu  i 


•,  HRZa  m> 


I; 


Rgure  30-3  continued:  ATH  Test  Script  tor  Testing  LLFIND  with  Timing  Analysis 
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•ad  I 
DOB  I 

cnoc  (  ‘SMOLr*,  auoLr,  ii>  ; 


TUT  CUB  « 


STMT. 


(4)1 

(  ‘ITBI  •>  rubblah,  tua  not  prsatat  ia 
(  'Uiai  ■>  umu.,  valid  LLBTTLB’  )  i 
(  ’BSaaLT  ■>  0*  )  ; 

(  •ujrmjmtjna.LimD',  •• 


bagia 

HUOLT  ixraBxnw  ->  •nibfaiah  •,  uxai  ■>  naan  I 

unapt  lOD 
•kaa  oelMXa  •> 

XUMU._BBCBfTX<M  (  'OthaKa*  I  ; 

•ad  I 


oon  t 

CBKR  <  •MtOLT*.  BUOLT,  0)  i 


CLOSB  SCRXfT 


BBD.SCBIPT  ; 
•ad  TBST_uraD; 


••  Bo  Stub  SiaulatioD  aaetion 


Figure  30-3  continued:  ATH  Tesi  3cript  for  Testing  LLFiND  with  Timing  Anaiysis 
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(cl  XMi  XafMMCictt  »ioo>— ing  htd, 


vcrcioi  3 >3 

UoMM  Mo:  tVUMaa  (laotltuto  of  OoCooeo  Nwly—o ) 


Toot  aaaulco  (oc  :  mT_Ll#nD 
•yocaoi  OonClfurod  (or  :  •on.OMXZ 
TMC  MMO  OB  la  MMT  (Ml  at  lltaS:U 


(TM(T_SOUrT:  nST.IXnM)  ,  «0R>  I 

RUir.Tim  ( 

. IMI  1  . 

■noRi:  uraD.nsT.m.uraB  , 

■ivaecad  Calla  ■ 

•  • 

■aoapeioB.Mat.a^paetad  i 
STMIT.TIMII  I 
tToa_TiMni  I 

SOB:  UraB.IMT.Ma.LLRMD  t 

amtx  (  nnu  i  itMam 

Itaa  1 

CHKK_n«:  (  aonjaHlX  ) 

TtMnjnum  •  o.oao  aseooda. 

. on  n*T  a  . 

. rut  a  . 

■mam;  uraojnar.m.iumD  , 

■apootod  Oalla  • 

t«o«ptiBOjaot_»j^oetod  t 

oom,  uMtmjmtjma.usrm  > 

oncK  (  nsobr  i  iw»Mtm 
xtaa  sa 

. . OB  W«T  a  . 

. TUT  a  . 

■aeon:  UMvmjrunjna.ujnm  , 

■moetod  Calla  • 

•  • 

l»oiptiBBjfct_«Mpactaa  i 
DOME;  ujnmjnnjrm.ujnm  > 
amcK  (  tmnta  >  ;pmib 

IMM  11 

Hgure  30-4.  ATH  Results  of  Testing  LLFIND  with  Timing  Analysis 


mcDii:  u^nB.nsT.vBi.uraD  . 
■^paetkd  Call*  > 

•  • 

■xeapttoBjtoe.i^paccad  : 
tarn-.  ujnmjranjna.uMjm 


(  lamna  i 

Xtaa  0 


_MUIT:  tanufxm  ; 


Hast  aaaulea  for  tanjOJnm 
Kaat  nm  eoa^atad  at  ll:35:S( 


•erlpc  Bnera 


Cbaeha  failaf 


•atha  with  (tub  tailvaoa 


Ovorall  Taat  thMB 


Figure  3(M  continued:  Results  of  Testing  LLFIND  witn  Tbning  Analysis 
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••  Kith  »C>Ui_laBnt_TtST; 

•ith  Lunm  ran  wmi 
uaa  UJnaD.tUT.m; 

--  wltb  tar  tataxaaead  Ptekmgtt: 
•ith  u^tmoMKrxamt 
uaa  U.  OKUMOnon; 


•-  TMt  script  laquixM  the 
•1th  ADwmrjnMBU.aaHMi 


uaa  of  the  MMj 


om  acupr 


proeattura  ranjuunm  la 
typa  nsT.BMIh  la  toeord 


WXCB  :  humii 


and  zaootdi 

MM_*UTa  :  eonatane  :•  t  ; 

TMbI  :  ooaataat  array  (i.  .MM.naTtl  of  ntTJMOh  :• 

(1  •>  (inM  ->  ••  •,  aiiCM  ■>  uniMi.,  an  i 

3  •>  (xxam  m>  •)  •,  waea  ■>  umia.,  m~ 

3  •>  (im  •>  ‘aMcUt  •,  astca  •>  opdop,  ixp.n 

4  •>  (im  •>  ‘rubbiah  •,  NKiai  •>  mioi,  anjm 

JlCT_nsin<T  :  lataparj 


KMET.tatziT  (  Tanjuajm’  )  < 

••  Paid  In  eha  taUa  to  ialtiallaa  lunaouaUK 


for  TBST_cakn  la  ThPU’caoga  loop 


nanjtan  (  tut.cus  i  ; 


warn  (  •upnDjnsT.m.uviiB*,  wsmai_Mor_iiPi 

bvfin 

hCTjiiioi,T  :•  urnD  (Tuumar.cMD.xnM,  TMuranrj 
oaeaptlea  ~ 


»  ->  1)  > 
Vt  m*  13) , 
«>  11). 

»>  0)  > ; 


(  'imour*,  tajuMiuT.  nmiamnjaaat  .anjmaaun  t 


Figure  30-5.  ATH  Test  Script  for  Table-Driven  Testing  of  LLFIND 


MMnT  HUMM  (e)  XtL  XafMMktloa  »rof«ing  UA,  iffO-tl 

w»nlaa  2.3 

Ueaaaa  Mo;  StLOaaa  Itaatlcut*  at  Oataaea  taalyaM) 


Taat  aaMlta  (or  :  nsTJUfttO 

tyataa  Oonflgurad  Cox  :  nojBOX 
loot  tan  OB  at  Mur  laaa  at  ii:a»:e» 


tmer.tcurr:  iut_u#i»  ,  amo  > 


HIT  a 


■ncvR:  LLraB.naT.fn.tLvxs  . 
■i^oef  A  Colla  - 
«• 

twMArlaBjot.Bopootod  / 
DOM:  XiraB.TUT.m.tXraB  J 


naoLr  i  iMsan 

IMB  1 

. mm  rmn  i 


Colla 


(  naOLT  )  ; 
itaa  33 


IWMT  3 


mam:  uraDjxsar.m.uraB  , 

■lyoctoA  Oalla  ■ 

•  • 

K>Btptlaa_Boc_BApaetod  > 

oatm-.  urm)_mT_pm.imm  ; 


OBoc  (  moLT  )  irasm 

Ztaa  11 

. no  WIT  3 


mum:  vunmjcanjna.unm  , 

ftq>o°**i»  Calla  • 
t»oiaticB_«ot_ti^aotaa  i 


Figure  30-6.  ATH  Results  of  Table-Driven  Testing  of  LLFIND 


DOiB:  utvmjnnjna.ujnm 


(  nsOLT  )  ;PM8*D 
ZtM  0 


DB  TUT  « 


■»_SCMrT:  TUT.bWXaD  ; 


Taat  Uaulta  (or  TUT.LLran 
Taac  ms  eaaiplatad  at  lt:Xa:M 


■erlpt  Imra 
Ctoeks  tasaad 
Chaeka  Tailad 


tatsa  wltli  (tub  Valluraa 


Oaarall  Taat  fAUIP 


Pigurs  30^  continued:  Results  of  Tabie-Drtven  Testing  of  LLRNO 
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«iui  u._BKUuwnGM,  Tirr.ioi 
uM  u._DacLMwinan,  nsr.xoi 

Mpunt*  iRun.Tnr.nga) 

proeaAur*  Mkm  is 


MkMna_IWK»i  ascapcloai  --  for  fotol  pasolng  orrero 
T 1  M>TIT*nr :  eoBOtant  :•  SOOi 

-•  aw  iwhor  oC  o— t— tioX  foni  oIsmbco  la  poxM  troo  ot  oao  ciao 


typo  uaxon  la  --  tor 
(oeord 


XnD;  UJmi; 


typo  UilUIUliJUt  la 


ooeabulary  ayobola 


--  ayachraa I aatloa  tablo  ladaa 
..  poBltlea  la  paoduecloa  right  baad  alda 
--  typo  of  aoeahulary  ayafcal 
••  ayahni  tablo  or  produetlea  atart  Inilar 


for  aaatantial  fo 


lAtiaoiD:  MOLIMi;  ••  la  thla  tba  rlghtaoat  child? 
lot:  ■■*■■■— I  --  palntar  to  laatchild 

MMBT:  mmRt  polacar  to  paraec  et  thla  aed 

unXBDR:  UARUKRI;  ••  dcrlvad  Mtrihutaa  xatuxBad 
tllXh:  lUlOR:  ••  ooeabulaxy  ayabol  iaforaatloa 

aad  raeord; 


u.To»i  man) 
tocofunr:  man; 
tJxociMi  man: 
LLsnms:  nmon; 
LLSTRCX;  array  <  1 


top  of  otaek  polatar 
location  of  ‘any*  la  llayhboltahla 
••  loeatlcB  of  aad-of-iaput  la  ayaboltablo 
••  ourroat  aaataatl  al  fna  olaaanc 
uaxtncK  I  of  Mjnwtnu.) 

•  •  ataefc  idilch  rapraaanca  tha  paraa  troa 


bagia 

JAUIRVni  )•  1; 

UttOf  :•  1; 

uuma(usnmiu  .imtckiw  nm, 
u8nac(U4Wfm«i  .annr  :■  ti 
uaxMacixuanniii  .nuh.snKHznK  :•  O; 
un»CK<uanTrnt)  .uxh.KiaD  :•  ■uwiaiaunL) 

••  flad  laootlen  of  *aBy*  la  llayaboltahla 
XAOOfUPT  I.  LliPm(  (l»'a',  a»>'a',  othoca  ■>  '  '). 

-•  find  location  of  oadofoouras  (*o*)  la  llayaboltahla 
Ijjtygot  )•  LLrm(  (la>'d',  othara  •>  '  ').  ObOOF  )) 


aad  FMn,- 


Figure  30-7.  ATH  Example  Invocations  of  LLFIND 
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with  u._aKiMiitnaw,  nsr.xo,- 
puiu«*  n>n_n8T_nu  is 

uss  Lt_OBCUUMTXaM,  nXT.ZOi 

typs  usTXLB  Is  (urnuu..  MowMcm..  oaoor.  hcnoi.  shstii); 

cyps  usyifnaMny  is  ••  tor  syhnl  tahls  sotrlss 
rseoxd 

OT;  unUMS;  ••  llcsxml  stxlop  or  protv  Idsotlflsr 
KXW:  Uiimii  --  lltsrsl  OK  SXtWV 
sod  roeosd; 

iLgnmovoMM:  sxrsy  (  i  . .  uoMUMxn  t  of  LbaMzaumzi 
••  ths  sjchol  tsUs  for  lltorsa  tszas 

proosdiiKS  PAMli 

tunetieo  uraD  I  mt:  ixsiuaui  mcB:  LLSmi  )  Kstum  umaut; 
proesdurs  BnDQRM; 

sod  MtaaBjnnjnoi 


paeksps  body  SAIStJRSr.tBS  Is 
proesdurs  PMn  Is  ssparseo; 

ftmecien  unm  (  xnM:  umnos;  «Hia:  LLsmi  )  zstum  man  is 
aspsrata; 

proesdurs  WslWPim  Is  -•  rssd  gtmmmx  froo  disk 

oit  cmwcm; 

tUBUM:  mi.TVM;  ••  sbars  grsnir  Is  stotsd 
begin  ••  ■■kIMMII 

o»Bi(  Lumoi,  n_mi,  •nau*  )| 

••  road  la  sysOal  eablss 

for  1  In  1  ..  IMWmMTM  loop 

tor  j  In  1  ..  uanmnuMPM  loop 
one  liumn,  uurmmatuMW  .tMtw  ii 
sad  loop; 

aR(  UdHAM,  Oi  ) ; 

*Kis_un(  uaum  i; 

If  CH  •  '9'  than 

udnaouiMUii)  .ran  i«  aaoDP; 

olso  ••  ssn—  eb  ■  1 

uranoumud)  .ran  >•  utom.; 
sad  If; 
sad  loop; 
aon(  LKaaM  t ; 
nsDoiuyi; 

sad  nwn_TnT_pia; 


Figure  30-8.  AdaTEST  Declaring  PARSE  and  LLFIND  as  Separate 
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vitii  tMsa^nsT^vn;  ~ 
uM  »Mn_naT_mt 

-•  with  any  Mfanoead  raekavaa: 
with  U._I>KLMUkTXam; 
uaa  uJudJUMTiani 

•  ■  Taat  aeripc  xaqulraa  cba  uaa  at  tba  KittJS 
»lth  MuaBST.MUaua.CONMBS  ; 


oral  SCUFT 


pracadura  lUT.PMfS  ia 


axMT.aaiivT  (  •nar.PABn*  )  ; 

--  ftaad  la  aha  cabla  to  iaitlaliaa  LLnMdAhBU 


TUT  cut  1 


toutr  ntr  (  i  )  ; 

tlicorl  I  •MMl.TUT.Ma.Fttn*. 

•IXraB:l;  U.rxit>.-1*, 

ixciprxa«_an_BPKnD  i 

bapln 

tMtli 

aasapcioB 
uhaa  othara  -> 

lUMM.  tctctmom  <  'OtiMra*  > 


•  •  cut!  taurr 


an^iauiT  ; 

aad  nsT.FMtt; 


••  MuouT  mmss  stub  for  unm 


uich  «DKmT_H»OTSt_sra_tiinunaH: 

uaa  tiuauT_mns8_snB_iiM)UKnai; 

aapaxaca  (PMnjRR.rai) 

fuaecloa  Uran>(  ITBI:  URUMt)  aacRt  U«TTLB  )  raCum 

1W_ltlinai_vgaflt  latagar,- 

hagla 

txMR.nTs  I’uraD'i) 
eaaa  akLL.BB?  la 
ukaa  1  ■> 

rtrjurmjmum  :>  iti 

UtMB  3  •> 

nv.tsioni.viuai  :•  tt 

uiian  etiiara  ■> 

zunu_ctu_>fr; 
nv.amnMfloat  :•  o> 


xaeuiB  (lllp_nRmi_WhXa» ; 


Figure  30-9.  ATH  Test  Script  Showing  Stub  Simulation  for  LLFIND 
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Figure  30-10.  ATH  Results  of  Test  with  LLFIND  Stub  Invocation 
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4  --  Plad  Icaa  la  ayabol  eabla  ••  xaeum  Indar  or  0  If  aoe  found. 
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A  noi  ;•  LZOMZXSZSI  «  1; 
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35  :  and  LLPZWD; 

3( 


MALTSZS  XttWOKt 


Analysis  rsport  on  fils  llfind.a 


Msasurs  Valus 

ossNorrs  p 

OQMBrr.Lzms  o 

ADA.OOOB.IZnS  2 


Lzns.zii.sooRCi^rzut 

TODa.TMZTS.ZII.MmCB.rZU 


2€ 

1 


PMOMM 

menjsumBs 

08S.CLMIUS 

ooMPzuiTzovjanTS 

pjyacMai.snczvzciaiQn 

samooiMi.snczriCKnon 

aDBRZc.mczrroiTZQm 

PACXAOi.BODZBS 

SWHOQilttl_»OOI18 

Qgniac.iastiufTiATXOMs 

SOKWITS 


0 

0 

0 

1 

0 

0 

0 

0 

0 

0 

1 


BB  or  Kgpcsrr 


Figure  30-1 1.  ATI  Static  Analysis  of  LLFIND 
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Figure  30-11  continued:  ATI  Static  Analysis  of  LLFIND 
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Figure  30-11 


continued:  AH  Static  Analysis  of  LLFIND 
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•  •  atth  pwnaBjnnn.iUT: 

with  iiL»na)jratT_pni) 

UM  UiFI>D_TUT_Kai 

•  •  with  any  Itafanaead  Paekagaa: 
with  IX.eKUUUaiOM; 

uaa  U.jaKlMMKTUMSi 

•  •  That  aeript  raquicaa  tha  uaa  of  tha  jatl_OOMBUBS  and  JUBOirsZS  packagaa: 
with  JII»nST_KMai«_OaMMMM  i 

uaa  »p»T«aT_taaaaat_maoi  i  ■  i 
with  ABMwIliMnU.MBktMIS; 
uaa  hDasMTjmiaMM_Mya.yaisi 


--  oam  tozar 


preeaduxa  naTJUran.MBOiTSIS  ia 

--  Inataatlatleoa  of  Oaaarie.Clia^  if  naadad: 

typa  Lums  ia  (liimUU.,  KIMMim,  OMOP,  hCnCB,  PATOI)  ; 

••  Daeiara  uork  wariablaa: 
r«  !  taannas; 
maa  iLsmi: 

nSOLT  i  ZWTWWi 
bagia 

STMX  acupT  (  •nar.iLPiiDjimLms*  ) : 
mniusajununzt  > 
atrjmcM  <  nuca^pmu. )  ; 
axaxr.oovaaaaa; 

•  •  Baad  lo  tha  taUa  to  lalcialiaa  UPtlTilTaiTa 
UhOOPM; 


T88T  PiOHa 

TUT  CUB  i 


8TWr_1BST  (  1  )i 

(  'ZTIM  •>  a.  lot  itaa  la  tahla*  ) ; 

(  •anCH  •>  1*  )  ; 

(  'inUlILT  •>  1«  )  > 

■neon  (  •unB_Ti8r_paB.uriaD>,  •• 


bagia 

aaaoLr  :•  upiudnM  ■> 
aaeaptieo 


>; 


BKCK  •>  LXmhb)  I 


Figure  30-12.  ATH  Test  Script  for  Coverage  Analysis  and  Full  Tracing  of 

LLFIND 
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ZUMU.  navncM  <  •oumts*  >  i 


ancx  (  'naoLr*,  aHiiLT,  d.- 


Swlteh  off  tnelag  for  tho  roaaiador  of  tho  toot 
nor  oonxMi; 

SR  lua  c  nua  an  t; 


TUT  CftSI  2 


nMTJRST  (  2  ); 

(  •zm  •>  ).  loot  itoa  In  cnblo*  ); 

(  •XHZCM  ■>  1*  ) ; 

-  •  OOMDR  (  •naDLT  •>  22*  )  : 

giMcuM  (  •uMimjnrtjm.uMaB’,  •*,  wicntimjKit^anaau  i; 


bSffiA 

nsDiff  :•  itranczm  •>  •) 


■ .  WZCB  •>  LZtnJO.)  ; 


•boo  otbora  •» 

ZUMIOi.CXCnTZOM  (  •OOrnn'  ): 


(  •MSDur*.  nsoiff,  321  i 


Tin  CUB  2 


tiurjim  (  3  ) ; 

(  •mu  •>  chuue, 

(  •«azcB  •>  OMor*  >  > 

••  COMUrr  (  •BBSOLT  ■>  11*  )> 

uBconi  (  •ubRMD.BBn.na.zu'zaD*.  • 

bogin 

naoiff  :•  uranizim  •>  •oiarUt 
•aeaprlon 
DlwB  otiwro  ■> 

XLumLWtcaaiai  (  •oturo*  i> 


•ntry*  )i 

BXCBrTZOM.Wn.BBnCTBD  )t 
• ,  anai  ■»  orod*)  i 


I) 


(  *1 


.  311; 


wnrusT; 


CUB  4 


TBBT 

8XMTJIBST  (  4  ); 

(  'XTBi  •>  rahblBb,  itoa  not  proooot  in  tabla*  ) ; 

(  'ORZCH  ■>  UTBIMt,  onlid  LbBTXU*  ) : 

(  •USOLT  •>  0*  )  ; 

mcm  (  •u<rzBD_iB8T_m.ztfza>*.  **,  acMmmjm_nncm>  ); 

bogin 

Figure  30-12  continued:  ATH  Test  Scr^  for  Coverage  Analysis  and  Full  Tracing  of  LL- 

FIND 
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irtMB  otbaca  ■>  A 
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Figure  30-12  continued:  ATH  Test  Script  for  Coverage  Analysis  and  Full  Tracing  of  LL- 

RND 
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Figure  30-13.  ATH  Results  of  Coverage  Analysis  and  Full  Tracing  of  LLFIND 
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Figure  30*13  continued:  ATH  Results  of  Coverage  Analysis  and  Full 

Tracing  ot  LLFIND 
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Figure  30-13  continued:  ATH  Results  of  Coverage  Analysis  and  Full 

Tracing  of  LLFIND 
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Figure  30-13  continued:  ATH  Results  of  Coverage  Analysis  and  Full 

Tracing  of  LLRND 
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buftT_input_—t» .  • 


BeB>9aauie  note  co  Mrk  «romid  viBS  parotolaa 


■Itb  Ba^lnltloBS)  UM  DaClalciaaai 

pMfciwa  mmm_vumjmaa  la 


•in  ;  MOOMLi 


> 


prooadux*  IWUHlfH  (Z:ia  Cf.fOnKr)  i 
proe*4un  mw  (Z:auc  CT^foaMkrti 
psan*  man  tnuuw.wuoiui)  > 


•nd  MW  f u_m(n'jmw  i 
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•1th  Caltadari 
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aatry  noon  (I  :1b  CT.wmKTt ; 
aatxy  MUUWM  <I:aut  CF^fOMKrl  t 
aod  Barm; 


taak  ba4]r  MWflR  la 

•ubtypa  mn_Tm  la  foriTIVI  raaga  1.  .Sin,- 
aubtypa  OOOWr' Tm  la  naOWL  raaga  O..SItt; 
MW  :  array  (inn.Tm)  at  CT_fOMMT; 
rnnr  :  mn_T»w;.i» 

OOOWT  :  COaR~ Tm:>0; 

now  :  cy.raanz; 


bagln 

•hiZa  aot  rinlabad  loop 

aalaet 

aeoapt  BPQUIUB  (ItlB  o.fonna)  do 
it  BatialtieBa.Mma  th«> 

Taat.Ze.tut.Idaa  (rotaait  .TlaMt_laawt  (Calaodar  .Clock)  a  •  *  a 

■Butfar_IaputJlno  about  to  aaquaua:  *  a  Z)  ; 

•ad  It) 

It  OOaRT<ain  thas  --  ebodt  it  raqiiaat  Ipaorad 


innr»<innT  aod  MW'Utfn*i; 
ooowr;«couw*i» 

•Dd  Itl 
and  ■MW; 


or 

•hao  C00Pr>8  «> 

•ooapt  MQaadtout  CP.fOMWI  do 


Taxc_Io.Mit_ldaa  <PoTaat.Tlaa_] 
•Mittar  laputjnga  daquauad:  • 
•od  It; 


ICaloodar. Clock) 
W)> 


a  • 


»»Mt  ngnm; 

BMDra:a(nW)«B  aod  MW’LhST)«li 

OOOMTiaCOQWr-l; 


a 


Figure  30-14.  ATHListing  of  BUFFER  Package 
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May  10.0; 
•od  Mlact; 
•od  leap; 


proeadus*  IWOCmil  (Z;iB  Ca_fQMMT) 
bagla 

aalaet 

■OPym.lMUUMd) ; 

alaa 

null;  ••  Haquaat  IgBorad 
and  aalaet; 

•od  UQUWU; 


ia 


pxeeadura  UdUOdGl  (Xiout  Cr^fOMkiri  la 
bagln 

BOVfB.UMUnd  (1)  ; 
and  tMOOBS; 


Rgure  30*14  contlnued:ATH  Listing  of  BUFFER  Package 
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--  aith  vAcnajD 
with  aovm.zMKir 


••  «ttb  any  ••farapoad  raekagaa: 
aith  DvoRTxan,  PomTi 
uaa  BVXnTXOn,  fOMMT; 

•  •  Taat  aerlpt  ca^raa  tba 
aith  hByamsT_naaiu_coMMi 
uaa  M>iain_HUdBas_COMMi 


uaa  oX  tha  JI3H_0 


•-  Taat  aeript  xaqulraa  tha  uaa  of  othat  ASH 
aith  A0»I1«T_»MM8_0— IC.qaCM  ; 

alth*M»3UT  ll»iwi«_TninB_lMB>LT«I8  ) 
uaa  ADKn8T~ mwiu  Tiimn_Juni.Taxs  ; 


procadura  TSST_mfUt  la 

..  inatantlatioaa  of  daaarie_Chaeka  If  oaadad: 

••  Daclara  aoafc  aarlablaa; 

USOLT  :  a.rOMT.- 


arwtr.schxpr  (  •nsr.aovm*,  •mwjomx*  )  ; 

caman  (  ‘A  aarlaa  of  taata  to  ehaefc  haialllna  of  FIIO 
--  naar  ha  raaat  hara  for  tladag  aaalyaia  latar  la  taat  aeript 


••  TBOT  PAXnS 


TB«T  CAU  1 


8TMtr_TUT  11); 

•-  OOMttW  (  •■aquaua  lat  itaair  AAAAA*  )  ; 

-•  Sat  initial  aaluaa; 

••  Introduoa  call  to  Qhlt_undar_Ttat  aith  Call_l<lot  and  XB_laeaption_Sjqpactad: 


Figure  30-15.  ATH  Test  Script  for  Testing  Task  BUFFER  with  Timing  Analysis 
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•  >  Mak*  call  to  1lDit_und«r_T0*t  with  appropriat*  valua(a)  for  in  paraaMtara 
••  and  work  variablaa  for  Out  paraawcara  and  racumad  valuaa: 

BUFraR.INPOT_l0OS.»QOTO  (2  ->  -AkkAk*); 
dalay  1.0;  ••  Allow  procaaaing  to  ba  parformad 

Bxoaption  haadlar<a)  : 

axeaption 

--  If  taat  eaaa  raquiraa.  provida  a  Corract.lxcaptlon  handlar.  a.g. 

•-  whan  PACKAQB.QRCllt_fVST.SXPSCTSD_BXCSmOII  «> 

COtUUCT.tZCIPTICtl  (  ■KXPICnD^KZCBPTrOII* )  ; 

••  Alwaya  prowida  an  ZLLtOkL.CXCtfTZOV  handler  for  at  laaat  'othara'  : 
whan  othara  ■> 

XIXIOAIi.CKClPTIOM  (  •Othara*  )  ; 
and  ; 


•  -  Check  the  raaulta  of  axacuting  the  Onit^tadar.taat: 
Out  paraaatara/ratumad  value 
Global  data 

CHiCKjrziiiR  (•stanjoirxk*,  o.oooo,  o.ooos); 

IKD^TBST  ; 


TI8T  CASE  2 


STAKT^TSST  (  2  }  ; 

-•*OQMBffT  <  -tofiuaue  2nd  itaai;  BBBBB*  )  ; 
sneoR  (  ■wiFrmt^afpOT„M8a8.>urf«R.Mqonnf , 

m  ■ 

BX<XI>nOM_ROT_SZPCCTID  )  ; 

b«9in 

•nmit_iinnir_iiso8.nQDiCT  ii  •>  •BaBsa*).- 

delay  1.0;  Allov  ptocaaslng  co  ba  parfonwd 

axeaption 
whan  othara  •> 

IliUaiU._BCCIPTXaR  (  •othara*  )  ; 
and  ; 

Don  ; 

B1ID_TBST  ; 


test  ease  3 


RSSCTJTIlBil; 
snartjtEST  (  3  )  ; 

-•  COMann  (  'Oaquaua  1st  quauad  itaa:  BBUB'  )  ; 
mans  (  *BnTnR_xinoTjisas.bUFnR.i»QDiDB’, 

•  a 

tx^  .TZOmjKfTJBOECnD  )  f 

Figure  30-15  continued:  ATH  Test  Script  for  Testing  Task  BUFFER  with  Timing  Analy¬ 
sis 
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■orm_iaFor_Msas.oigiiBa  (  naavt  ); 

aalay  l.O;  -•  Allov  proosMlng  co  ba  parfonMd 

•xcaption 
Khan  ochara  •> 

lUMkL.ncipnail  <  ‘Oehara*  I  ; 
and  ; 


OOHl  i 

cncK  ('DioaoiD  vbum*,  nain.T,  ‘AMM'I; 
oncK.Tim  (■som.twis*.  o.oooo,  o.ooosi,- 


IMB.nST  ; 


nn  ciLSB  4 


ann.iUT  (  4  > 

--  OOMnr  (  'Baquaua  and  quauad  Itan:  HMU*  )  ; 

moDR  (  •■omii_i»OT_iaas.nrm.DBaGBiiB*, 

•  • 

■ZCBmOtl_NOT_BS»BCRD  )  ; 

baqln 

K>rm_XKPIIT_MSaS.OBQaBOI  (  HSOLT  >; 

dalay  l.Oi  -•  Alloa  prQeaaaiag  to  ba  partozMd 

axoaptlen 
than  ochara  •> 

lLUlUL_nciPTiai  (  *Othara*  )  ; 
and  ; 


oon  ; 

OttOC  (•UQKno  VAUB*.  BBStltT,  ‘BBaBB*); 
SHD.TBST  ; 

-•  CXOSB  8CBIPT 

BID_8CBIPr  t 
and  nST_BOrFBB  ; 

--  Bnd  of  aalu  Taac  8erlpt  aactlon 


Figure  30-15  continued:  ATH  Test  Script  for  Testing  Task  BUFFER  with 

Timing  Anaiysis 


AdaTIST  Hanws*  (cl  IK<  InfexMtioo  Prooacaiitg  Led,  l»*0-»3 

Version  3.3 

Lloense  Mo;  SPLOSiS  (Xnaeicuto  of  Dofonco  Jduilyaosl 


Toot  itoaults  for  :  n>T_WJVPIR 

SyocoB  Conflguzod  for  :  SOMSJIXIX 
Tost  Bun  on  IP  HMT  1«P3  at  13:03:33 


STUlT.SCiafT;  nST.BOPPBR  ,  SOMS.aMIX  ; 

--  A  sarias  of  eaaea  to  ehaek  handltnj  of  PZfO  quaua 
MMSKTjrim  I 

. TIST  1 . 

■XMom:  MOPPBR.iMPirrjMsas.BUPnB.BMgaraB  , 
■jvacead  Calls  • 

■  • 

■aeapcien_Mot_lapaecad  t 

OOMB:  BOPraB.IMPtrr.lBaS.BOPPBB.BNOOSDB 

CKBCr_TZIIBB;  (  SOMIJDMIX  )  ;PASSBD 
TXMBB_«MflB  •  0.000  saeends. 

. BMD  TBBT  1  . 


BIBCWB;  BOPPBB_nlPOr_MSOg  .BOPflR.  IHOBUB  , 
Bi^aecad  Calls  » 

«« 

Bxeopelon_Mot_Biipaecad  ; 

DOMS:  Bapm.zMPOT_iaas.BOPm.BMQ(ncoB 
. BBD  tww  3 . 


BBSBTJTXIBR  j 


TIST  3 


BXBCcm:  •aFPBB._xMpaT_MBos.aamR.oigaro  , 
B^psccsd  Cadis  ■ 

•  • 

Bxc«ptlcxi_M0t_lJcp«ctwl  ; 

DQKK:  BOrVBR.IinOTJIBaS.BOmR.DSCOIDS  ; 

CRICK  (  OIQIOID  V31L0I  )  ;MSSSD 

xtw  -Mm* 

CBICK.TXm:  (  SOQJRIXX  )  ;PASItD 
TZm.VRLDI  «  0.000  MCttidC. 

- . HD  T*ST  3 . 


Figure  30-16.  ATH  Results  of  Testing  BUFFER  with  Timing  Analysis 
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. I«*T  4  . 

IXICOTl:  Kimlt.lVOr.HMS.KIFm.DiaaiDI  , 
li^ccad  Calls  a 
•  • 

txe«ptioa.MoC.Si^ot«4  $ 

DQMB:  BOmR.IMPOT.MBaS.BOmR.DBaOiai  ; 

OSCK  (  OBQBDID  VRLOl  )  /PASnO 
ZtMl  "IMW 

. nD>  TMT  4 . 

DD^SCRIPT;  tmST.BDPPBR  ; 


Tast  Bttsulta  for  TIST.BOfflft 
TOflt  run  eenplotod  nt  12:03:3? 


Script  Irrora 

CSkoelu  PnOMd 

Choclu  Poilod 

CtMckn  Zpaorod 

Pntiui  with  Stub  Pailuroi 


0 

4 

0 

0 

0 


Ovoroll  Tost  PASftCD 


Figure  30-16  continued:  Results  of  Testing  BUFFER  with  Timing  Analysis 
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•  •  «ith  »ACXM1S_QHDBR_TIST: 

«ith  wamtL_immjtaaat 
UM  KimR.iOTorjaaCi 

•  •  with  any  ■•fanoaad  Paekagaa: 
with  osrnaTzaas.  voaMKi; 

uaa  omnnoHS,  nianT; 

•  ■  Taat  acript  raquiraa  tha  uaa  of  tha  h3M_ceaaiMB>s  padcaga: 
with  hi>»!mT_HMaass_ccMnB>s 

uaa  hDKnar.nmBss.coMHMDS  < 


-•  opn  scuPT 


pzoeadura  nsr_BCIPfSK  ia 

••  Daclaza  work  woriahiaa: 
typo  ACT10«_TyM  ia  (IROOBn.  UhUUMI  ; 
typa  nSTjMXh  ia  roeord 
hcrxaM  :  hcnop.Tm; 

■Ngran.nipor  :  cp_faiMkT; 

IIBgnDl~«BSin.T  :  CP_fQMtkTt 
and  raoezd; 

TMUil  ;  eonataat  array  (1..13)  of  1UT_IMXh  :■ 

(1  •>  (ACTzoii  •>  amgama,  naam_imm  •>  •»»»»»■,  DaQoiiii_MsoLT  •>  'zmc) 

2  ■>  utcnoM  ■>  noDim,  amacmfnTzmim  •>  ••UBa*.  nsgaiiiiliiisaur  •>  *ztzzz-i 

3  ->  (hcnoH  .>  iMguiw.  nooBs.zsFor  •>  •ccccc*,  ncDtra_aBSi]i;T  •>  'zzzzz') 

4  •>  (hCnOH  •>  ZPQUZUZ,  ZMOOZOE.XIPDT  •>  •Cem*.  II10UZUZ_ZZSPLT  ->  ‘ZZZZZ* ) 

s  ->  utcTzoa  ■>  MQozoz.  zaaozoz^woT  •>  ‘zzm*,  uzQuzui.zismir  •>  ‘zzzzz*) 

t  m>  (hcnoH  •>  zwuuzuz,  noooz.nm  ■>  •wwnf,  aatfmnjusaut  •>  ‘zzzzz'i 

7  .>  <hcn(at  •>  gpouzoi,  zaQonz.ZMor  •>  ‘ocnaa’,  tmaaamjumBa  •>  ‘zzzzz*) 

(  •>  (hcnoi  •>  ocaoni,  zHQoni.imT  •>  •mrr’,  oaatMmjmsoLt  m>  ‘juum*) 

9  ■>  ucnoM  s>  DzgoEaz,  ZMOom.nmr  »  ‘trm*,  oaQanz.aisoour  •>  ‘inu*) 

10  •>  (hcnoM  m»  tmgcmaa,  ammaatjunm  ■>  •rmt’,  tmaamjaBax  •>  ‘ccccc* 

11  •>  (hcnow  «>  OBODZoz,  Km/avMjaam  •>  ‘rmr*.  siiQDm_uSDi;r  »  •»«»• 

13  »  (hcnoM  ■>  ozoDioz,  zpuuzoz.OBot  ■>  •rmr’,  laoamjuMaLv  •>  ‘zim* 

ii  •>  (hcnoM  DZODRiz,  zNoozoz.inrar  •>  ‘rrm’,  oigiiiDZ.zzsaLT  ■>  ‘rrpFr* 

USaVt  :  CP.fOZmT; 
bagin 

STMT.sauPT  (  ‘TZZTjnmii*.  'SianjDnx*  )  > 

OOHnn  (  ‘A  aariaa  of  taata  to  ehaek  handling  of  PIPO  guaua*  )  i 
tor  zsar.ckn  in  XABU'mnga  loop 
STARTJTmgr  (  TZZt.Catft  l  ; 
bagin 

BKOiz  (  •mimR_amnjaaM.wamii.’  a 

jicnaMlTZPZ'znaz(TAzi«m«r_cAni  .Acnoii , 

■zczpnan.aoT.ixficxzD  )  ; 

if  TMUZCTSR.CIUW)  .ACTIOM  •  ■■guzUZ  than 


Figure  30-17.  ATH  Test  Script  for  Table-Driven  Testing  of  BUFFER 


•IM 


.agOIGX  (I  •>  TMU(TWr_CMB)  . 


i_mOT) 


■OFm.XaffTT.MMa.BKOOnB  tuanLTi: 

■od  it; 

daisy  1.0;  --  Alloa  proossslng  co  ba  paxfoxaad 

aiteaptieB 
ahan  othara 

lUnAL.nCBmOM  <  •Otban*  )  ; 
aad  ; 


If  t*BU(tiaT_CASI)  .ACnoM  •  WBOWt  than 

(•MOioBD  VAlOl*,  AUCLT.  TULint«T_CAn)  .OaODBOt  BBOOLTIi 
if; 

I 


aad  loop; 

BD.aaupr; 


Figure  30>17  continued:  ATH  Test  Script  for  Tabte-Driven  Testing  of  BUFFER 


JtdaTlST  HaziMM  (e)  IPL  lafonuktlon  trooaMing  Ltd, 

vazaioB  2.3 

UcMM  do:  sn«0323  (Inacituca  of  Dotonea  Jtoalyaaa) 


Taat  aaaulta  for  ;  nST_K>m]( 

Syatan  Conflguzad  for  ;  SOnjORX 
Tast  Run  aa  31  mr  ISSJ  ac~  12;4C:30 


nMtr_scRii>r;  Tur.aamR  ,  sanjmx 

--  A  aariaa  of  taaca  to  ehaek  handlioR  of  rxro  quaua 
. TMT  1  . 


mOIR:  ■UfFRR.mPr.MMd .BOFRIR ■  MOORDR  , 
bvaeead  Calla  • 

■  • 

■MO^ptioB_aot_l^paetad  ; 

Doaa,-  RomR.zmir.MMR.RomR.iagiini 


ncctnR;  ■umR.ntar.MMR.aomR.RNoaiQB  , 

■ivoetad  Calla  • 

•  • 

Rxoapciaa_aoC_R9aecad  ; 

Don-  wmR.npOTjsns.RorRx.nsaiaB  ; 

. OB)  ftST  3 . 

. TMT  3 . 

BBCtm:  nmii.xinvr.iaas.KimR.nooaaR  . 
Rivaetod  Calla  • 

•  • 

■soaptlao_aot_Riq>aetad  ; 
oou;  aumRjnamjBas.warwm.BKloKm  ; 

. tn  T»ST  3 . 

.  IRST  4  . 

BXBCDII:  ■amR_XOTTrjKa«I.BOrrBR.naOIDB  . 
iJVactad  Calla  - 
•  • 

laoa|>cian_aot_liVaetad  ; 

DOHR:  ■omR.morjaas.aovm.RRQaiDB  ; 

. BB  IMT  4 . 


Figure  30-18.  ATH  Results  of  Table- Driven  Testing  of  BUFFER 
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■urm.xmrr.MMu  .Mvm 

li^etad  Cklls  ■ 

•  ■ 

Saei^lGa_ltot_li9act«d  ; 


no  rut  s 

--  TUT  (  -- 


■avm.xnor.iBat  .Borm . 

Bivactad  Calls  ■ 
■xeapelon.Mot.HVMead  t 


rut  t 

7  -- 


■^paecad  Calla  • 
■Meaptlan_aot_Bivaaca4  i 


. rut  « . 

■omB.zBKirjaas  .aorfn.MWwuB  , 

Ij^aecad  Calla  « 


(  mgmo  vkuib  )  ituwu 
Itaa  ’UMH’ 
. BD  TUT  • 


tSST  9 


:  mimii_intrrjuu.mjrm.uaonr 

■BMCtad  Calla  • 

•  « 

ticoaptiaa_ltot_luacead  ; 

■orriR_i>p(R'_iBas  .aorrn.BiuuiuB 

(  MUWD  Vaum  )  ;PMSD 

Itaa  •■■■■■• 

m  TUT  9  ------ 


TUT  10 


Hgura  3(^18  continued:  Results  of  Table>Di1ven  Testing  of  BUFFER 
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I 


mem:  Mvm.zvoTjMsos.aorm.DigosDi 

Il9«et«d  C*12«  • 

•  • 

BxosptieB_Bot.Bj9«et«d  ; 

DOM:  Bomft.xOTor.Mas.Borvn.uQcnaiB  t 

CMcr  (  pauMD  vms  >  /kmus 

XtM  "CCCCC* 

. wm  wsT  10 . 


TUT  11 


mom:  somft.zuorjMi.BOTVtt.MQain 

ti9«etttd  Calls  • 

•  ■ 

■soapelaa_aoe_livaee«d  ; 

son:  Kivm.iiVOTjaiit.Bavm.oiaoiDi  ; 
cncK  (  otgnio  vkuh  >  .-pmsd 

Itaa  •!«»■ 

. mm  Twar  it . 


nST  12 


Ii9«etad  Calls  • 

•  • 

■>eapcian_Bot_li9aecad  ; 

DOB:  mTmR_zamjaaa.warm.utaa*aa 

(  OKmD  V2L0I  )  ;PMSSD 


■D  tlST  12 
1BST  13  -- 


■ncDR;  BamR_nn>or_Msas.BomR.DiaoiDE  , 

taqpaetad  Calla  • 

•  • 

■aoaptlonJkK.lapaetad  ; 

DOB:  ■Omit_iaFOr_iaOS.KIFPn.UaD>DI  ; 


BCX  (  UBUBUm  VM2I1  I  ;rMBD 
itM  'mpp* 

. mm  ran  is 


BB.SaUPT:  TUT_aaffB  ; 


Test  JIaaults  (or  TBr_MIPmi 
Taac  xun  oOBlacad  at  12:«*:«4 


Script  Bmra 
Oiacfca  Paaaad 
Chacka  fallad 
Oiacka  Ignorad 


tatha  with  Stub  Pailuraa  0 
Oaarall  Taat  BaSBD 


I 


I 


i 


i 


i 


i 


( 


Figure  30*18  contliuMd:  Results  of  Table-Driven  Testing  of  BUFFER 
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•  •  with  naamjammjtart: 
aith  Kivm.xifor.iana,- 
UM  Barm_UlfUT_HMS : 

--  via  any  aaCanoead  Mekaigaa: 
aith  onmnnan,  fOMtri 
uaa  mraiTZOn,  fOMKT) 

--  Taat  aertpe  raquiraa  Um  «aa  at  tha  am_O0MauM  paefeapa: 
with  MuauwtjmmtMajaamamt 
uaa  MBKntTjaimMSjBaaaMta  i 


Oaelara  nock  uariablaa: 

ntour  :  etjKmmai 

bagla 

(XMT_acazpT  (  •tUT.nrtn*,  •ran^onx*  )  ; 

OSMPn'  (  'A  aaciaa  o<  taata  to  ehaek  haadllng  o<  FlfO  quaua*  )  i 


••  TUT  MTU 


anur.TUT  (  i  )  ; 

•  •  oounr  (  •■aquaua  lat  itaai:  AAMA*  )  , 

■Mcura  (  •■opm_zptiiT_ua>.KiPiu.non>ai*, 
•roaaatTTlM.lMipa  >  l* , 
ncnTKai_MOTjnnciip  >  ; 

bapia 

■apm.xwm'jHos.noDm  (i  •>  'aaaaa*); 
dtlay  l.Oj  ••  AIlou  pxooaaaiag  to  ba  porConad 

aaoaptioa 
than  otbara  •> 

TTiJBM.  neUTIOP  (  •otbara*  )  > 
aad  ; 
van  I 

ODJIUT  ; 


TUT  CM!  3 


Figure  30-19,  ATH  Test  Script  for  BUFFER  with  Sample  Start  Simulation 


miajnMt  (  2  > 

■  ■~ccmmn  (  'inquMM  aod  uaaa*  1  ; 

mam  (  •■omB_x»or_MMs.K)rfn.naDm', 

*  Vookc .  TUh.IMV*  :  2  * , 
aatmamjmjBMcm  t  1 

bavin 

aorm.spoT.ioas.iaooBOB  11  •>  •■>»*); 

4al«y  l.Oi  ••  Allow  prooaaalng  to  bo  paxfoxbad 

aneaptloo 
■ban  othara  ■> 

nxnAL.txamQH  (  'otban*  ) 
and  ; 


no.nsT  ; 


1UT  CAU  3 


9X»ar_TlST  (  3  )  ; 

••  aoman  (  ‘Oaquaua  lae  quauad  Itan;  UMl* 

naoRV  (  •■a»nb_iavDr_MM«.bom».oaci)BDi*, 
*  ro(natTTlaa_Inaaa :  3  * . 
BomaijKii.ixPicnD  1 

bavin 


)  ; 


■amb.xbvorjaas.DaoaiiB  (  auoLT  i  < 

daloy  1.0;  ••  Allow  p«o€»aaiBv  to  bo  parfomart 

anoaptioo 
whan  othara  ■* 

IUJtaM._BtCBmoM  (  •othara*  )  ; 
and  ; 


non  ; 

OBOC  (•DhQKIKD  VAUH*.  noaiT,  •AAAAA'I; 


TUT  CAU  4 


■acmv  (  •■arvn.xuor.uu.aomR.ohgDviiB’, 

•rornnt.Tlan  Xaava:4*, 

aKimoh_acT_iznciB>  > 


bavin 

■ovnh.imiTjKMs.ovaarai  <  mavr  ); 

daloy  1.0;  •>  Allow  prooaoalav  to  bo  partoraad 


Figure  30- 19  continued:  ATH  Test  Script  for  BUFFER  with  Sample  Start  Simulation 
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•waptloB 
iriMa  oeteza 

H.MIULI. 


(  'OcIMr**  )  ; 


CLOSE  sotirr 


lad  of  —in  T—t  teripc  ■aetloa 


-•  Sm  for  fox— t.Tl— _x— go. 


••  Stub  olaulotion  xaquix—  ttaa  u—  of  t—  JOR  Stub  Siaulntlon  pockogo; 
with  JkiMnsr_HMunHS_sins_snsa«noM  > 
uM  bBiaiSTlHksasssItTi]B~sxMBiAnaa  > 

--  It  — y  xoquiro  u—  of  t—  rr— nSi  or  Oa— rle  Qiaolta  paefcagaa  for  Chacka: 

•  ■  vith  JtBmsTjnsaBss.ooMnuas 
-•  uM  jmoisTjotsasss.aaMSUDS  ; 

•  -  vitb  jmi>amsT~iassMSS_<is—«ic_aacss  ; 

--  UM  JkDi«t*ST3RMtnss.<isanxc_asRict  > 

-•  Stuba  ara  eodad  aa  Saparataa,  ao  provida  tha  Paekaga  — ; 
aoparata  (fox— tl 

••  Daelara  tba  Stub' a  —  and  pa— taxa: 

funetioo  Ti— _laaga  (Clock.Tl—  ;  la  Calandar  .Ti— )  raturn  STSXKl  ia 
--  X— tantlatlo—  of  Oa— rle.Oiacka  If  — adad; 

••  Daolara  uork  —rlabloa  if  any,  and  If  otub  ia  a  funetl— ,  daelara  a  variable 
-•  of  t—  oorraet  type  for  xatuxniag  Mt  —1— a: 

Bsnnijnuis  ;  snaao  (1..20)! 


StM(T_snB  (*fox— t.Ti— _lBaga*l  ; 

COM  CbLL.SSr  ia 
ah—  1  ■> 

Check  valuaa  of  In  pa— tarn  at  point  of  call,  if  naodod: 

Sat  raqiiirod  (kit  pa— tar  val— a  or  val—  of  ratuxo  variable: 
ssm0l_iauin  :•  Soquaue  ti—  1 

ah—  3  •> 

BRaWJVhUIS  :■  Bnouana  tl—  3 

ah—  3  ■> 

Rtnsil.VkUR  :•  Ooqoaua  tl—  1 


Figure  30-19  continued:  ATH  Test  Script  for  BUFFER  with  Sample  Start  Simulation 
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4  ■> 

imtjuijakun  ;■ 

At  and  of  all  elkuaoa  to 
handlor: 

iihaa  ocboro  •> 

lUBOAL  CALL  m  ; 


Ooquauo  tlat  2  -  -  * ; 

with  aivactod  calls,  prewida  tlw  lllsgal_Call 


--  It  Stub  is  A  tunctlob,  catum  tba  raturn  varlablS'. 
ratuxn  (Sinnai_V!ALail  ; 

--  Sxlt  tbs  stub 
and  TiBs^lMpsi 


Bod  of  siaulatioo  sactioo  for  Stub  Venut.Tiaa_iiaaga . 


Figure  30-19  continued  ATH  Test  Script  for  BUFFER  with  Sample  Start  Simulation 
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MalMT  Hunau  (c)  m  Irfoi—tloo  rrecMaing  Ud,  l*«0-*3 

vwraien  3.1 

Lieanaa  Mo:  «fL0333  (laatitut*  of  Datanc*  Jkaalyaaa) 


Taat  toaulta  for  :  ntT^HFfta 

Syataa  Conflgurad  for  :  mmijaKIX 
Toac  Bus  «B  30  MBV  ISti  at~  ia:3S:0« 


SZMtr_SC3U»T:  TBST.Mlwm  ,  fan_aMU  ; 

••A  aariaa  of  taata  to  chaek  baadliog  of  fXfO  quaua 

. I*ST  1  . 

sfxcini;  Barm_xOTOT_MMs  .MJf f BB.noaraB  , 

■j^aecad  Calla  ■ 

■ toraat . Tlat_Xaa9a : 1 * 

B«eipeioa_aot_ai9aetad  ; 

KAKr.Sra:  romt.TiaM.lMoa  i 
Ctdiijm:  Bafaraaoa  3,  Call  1  ; 

BK>_8m:  ronat.Tla»_laMga  ; 


TUT  3 


■XKDTB;  BUf «H_nBpr_iMa« ■  warm . ngam  , 
B9aetad  Calla  • 

■  tozaat .  Tiaa.nuoa :  a  ■ 

Baoaptloa_Moe_Bapaecad  ; 

RART  sr^-j:  Voraat  .Tiaa_Ia«ga  ; 
CRU._Hnr:  Hafaranea  3,  Call  1  ; 

nD.B'XUB:  feaaat.Tiaa_Iaaga  ; 


DOU:  ■omii_mor_iaos.KiFm.naDm>  t 


■ . . TtST  1 . 

MXMcmti  ■OFm_mor_iaas.«OFm.DBaoioB  , 

Siqpactad  Calla  • 

■  Fonat .  Tlaa_Xaaoa :  9  * 

■iioaptlaa_Rot_l3aaetad  ; 

STN(T_8m:  Fnmt . Ti— _Iaaga  ; 
CALI._nF;  IMfazanaa  3,  Call  1  i 

■a_sm;  F0xaat.naa_Iaa9a  ; 

Don:  ■0Fm_mor_iao8 .KJFm.usguKim  t 


Figure  30-20.  ATH  Results  of  Testing  BUFFER  with  Sample  Start  Simulation 
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VMim  )  iMMSD 


BUD  nrr  i 


■XBcon:  Borrai.iMPorjBas.Borm.raanai  , 

■i9P«ctad  Call!  ■ 

•  r  onat .  Tlaa_Zaag* ; «  • 
lxeapClon_Not_B>qiaetad  t 

SOKtjnOh:  rozBat.TiaM_lBaga  ; 
C»LL_m;  Hafaranea  4.  Call  l  ; 

tK>_SIUB;  FozBae.TlaN_laaga  ; 

DOME:  wimit  mOT_iisas.aorm.DiooiDB 


CHICK  (  raoniD  vioai  >  .-rAssio 

Xtaa  •■UBB* 

. IHD  TIST  4 


nD.SCUPT:  nST.BOmR  ; 


laac  laaulta  for  mT_IOfnH 
Tiaat  run  oo^ilaead  at  13:15:13 


Script  Irrora 

Ctaaeka  Paaaod 

Chaefca  Failed 

Chaeka  Xpnorad 

Patha  with  Stub  Palluroa 


Owarall  Taat  PASSID 


Figure  30-20  continued:  Results  of  Testing  BUFFER  with  Sample  Start  Simu¬ 
lation 


•  •  AdaTUT  laatrvMncar  ATI  V  a.l 
-•  <e)  IPI<  XnlezMtlea  Proeaaalng  Ltd 

--  Plla  typa  :  Anaoeatad  Aourca  Pila 
--  Tlaw  run  :  Pri  May  a*  10:01:S«  1**1 
--  Pila  aaaw  :  Au<Car_laMuejBaga.aCl 


-  laatziaantad  for  : 

Static  Analysis 
oaeisiflo  Oovaraga 
StatasMot  Coasraga 
SKOi^ian  Oawaraga 
■oolaan  Ooaaraga 


1 

a 

1 

4 

5 

c 

7 

I 

* 

10 

II 
la 
11 

14 

15 
1C 
17 

It 

1* 

ao 

31 

aa 

31 

34 

as 

ac 

37 

at 

a* 

30 

11 

33 
11 

34 
IS 
3* 
17 

1* 

3* 

40 

41 
43 


buf tar_iaput_aaga .a  -  oan>ganarie  cods  to  sock  asouad  PADS  problsM 

sith  Oafiaitiaoa;  uaa  Oafinitieas; 
paekaga  wamn_namjaaa  is 

sin  ;  MiaQmi.:«MkS_CPJHBaS> 

pcoeaduxs  IMOUtUi  (I:ln  CP_PQMAT): 
ptoeaduza  OSQUSUl  (Isout  CP_PQWAT): 
prana  mm  (uuusui.uiQaiui)  > 


with  Ta3R_Io; 
with  Calaodaz; 
with  Poraatj 

paekaga  body  ■OPPn_IIPOr_ltsaS  ia 


task  BOPPn  ia 

antry  nODKOI  (I: in  CP.PMMAT) ; 
aatry  MQOni  (I:out  CP.POaMRT)  ; 

and  SUPPIK; 


taak  body  suppn  ia 

subtypa  mn.TSPS  ia  POSITITt  raaga  l..smt 
aubtypa  CaaMr.TSPB  ia  MAarawa  raaga  0..tinr 
■OP  :  array  (majTSPB)  of  CP.PCMHAT; 
IMtSAT  :  XMDn_TT*t:»l; 

imovi  :  nmjrypsiai) 

OODMT  :  000R_TIPI:a0; 

rmm  ctjiomaas 


begin 

aiilla  not  Pin!  shad  loop 

oalaet 

aeoapt  IMBOHJl  (I:in  CP_PQBIMr)  do 
if  Oafinitiona.Oabug  than 

Tajct_Xe.Put_Liaa  <Poznac .TiaM.XMaga  (Calandar. Clock)  4  * 
■■uffor_Xaput_Hsgs  about  to  anquaus:  •41); 
and  if; 

if  OXMrraSin  than  --  chock  if  raquaat  ignorad 


to  and  ■OPPn_IIPOrjHt«; 

*1 


Figure  30-21.  ATI  Static  Analysis  of  BUFFER  Package 
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jkMftLTais  aipoitr 


Muayai*  r^ort  on  ftl*  buf(ar_iaput_Mg«.a 


■Maura  Valua 

OOHBIRS  X 

ooMnr.ions  x 

M»._cai>i_Lms  c 


l•zms_xI•_salIltc■_Rl■  ax 

Tom.jnim_xM_iQgKCi_nu  t 


mwiMS  0 

nm.ojuists  « 

ou.cuDssa  X 

oanuLKnaHjaaiTs  2 

MOtMOB.ancxriCKnoRs  x 

soBmoauM.mcmciKnQMS  0 

OMmiaejuKtnckTKm  0 

»jicnai_^MOxu  x 

fOBMmMN_MOns  0 

oanxc.xasiMRijaian  0 

SBwm  0 


BD  W  ttMKT 


taalyala  raport  oa  paefcaga  apseltioaetoB  nmil_xmiT. 


■aaaura  Valua 

TODa._Lma  1 

ooMBna  0 

coMnr.iass  0 

iuia_oaoi_Lins  s 

una.n.sooaat.mi  tx 

maa.onn.ni.saaiai.vxu  1 


maoMM 

wnM.cuons 

OSB.CLMDSU 

PlCU>ll»TIVl_«Ba— B8 

anRic_iiKuuuKRan 

OBMZC.nSTMRlWiaiB 

aicncnD_Huu)CKnaKS 

oKuicnD.aKviuiaRs 

MuviD.TTn.Mrannan 

aMOOTOM 


uiaiciu._OMDua<aiu 
*iU!naMM._QMU«rau 
•mxr  jiddub  onuzcM 
mimjioormjanMKnu 
■DisiPLTan.amuaau 

triaasT_pncDnajom»an 

saai(r_ciKaiT_caMtiK)L_KMa 


0 

0 

0 

0 

0 

0 

0 

0 


Figure  30>21  continued:  ATI  Static  Analysis  of  BUFFER  Package 


92 


. BD  or  Bsratr . 

Analysis  rsport  on  paeksos  body  ■OPm.mtrr.MQS 

Valtks 
10 
0 
0 
s 


Tono.  itzns 


ABk^OOM  X^MU 


unt.m.aooKCB.fziA 
vom.  iMXTt  n.sooiici  PZX4I 


WITH  CLADW 


•I 

« 

0 

1 

0 

0 

0 

4 

0 


ptMUJaoaim 

‘cMnWMIO— 


Mor.snM 

mxvnjrm.ocraonon 

ALuaotMt 


0 

0 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

0 

0 

0 

0 


zfjgaammm  o 

BLSXF.VARn  0 

njujf$Kn  0 

CMjnKmmns  o 

CAn.AunnKnvBS  o 

bOOF.STKTBnn  0 

POR.XOOM  0 

«IXLB.XXX>FS  0 


MUKKjraawmwtB  o 

UMC.SdClMArXVS.FAlETS  0 

Aoarr.RATaam  o 

sucr.ttiaBBm  o 

mSCTTVBJMAXTS  0 

nucrxvi_«RZT.ALxnHKrxvis  o 

TBMmns  0 

OQMXXTZOAL  nmorjoaiLf  o 


Figure  30-21  contliMNd:  ATI  Static  Analysis  of  BUFFER  Package 
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94 


Qtt^CUtlSSS 

XttBft.Otl.CLMDnS 


vaof  attammm 

rat.uMM 

waiM,jjootu 

WWtXJKX90WtBKtB 

■xocK^oaoutfUdrxvi^vMnrs 

AOcm.imuMrs 

tmuKrjmxmmmn 

mactivijwaTjttauwnvM 

cammana^wmaaijaius 

TsmDjmtnjcms 


IKCWTICB, 


0 

0 

3 

7 

17 

0 

0 

0 

0 

0 

0 

0 

7 

2 

0 

0 

0 

0 

1 

0 

0 

0 

3 

0 

0 

D 

0 

1 

0 

1 

0 

0 

2 

1 

1 

3 

0 

0 

0 

0 

0 

3 

10 

0 

3 

1 

0 

0 

0 


Figure  30>21  continued:  ATI  Static  Analysis  of  BUFFER  Package 
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■KLmap_aa|_angoi_oraaKroM 

wturtnB  TODa.aoMjonBiaau 

mMrnB_mmjmxQimj»mma 

munw_nxu._aiai_ovnMns 

■ttRiKD.unni 

■tump  yocMDLMtr 


nLinw_ixncnD_iMni 

■Himw_>aBZTT_iuaio 

numDjratoB 

■atms.nrmmB.nBOKs 

mum0_ion>mL.«ouiB 

■Miaiitti_tjnmi<_op_«UTWicTioa 

lUMlwIiaT.UVILJMaTMCTICM 

MMunattTnoaniijatoKt 

MMMtnPjrBajumBm 

KMiaTBRB.ozmcDLnr _ 

nuTBiu)_uunraa>_uvsL _ 

■kumaTmiLLiaBRi.oafnR 


aat.M 

l.SC 

aas.it 

o.ac 

1.00 

0.01 

o.o« 

asisa.ot 

taio.aa 

101.17 
0.00 
14. as 


MtatMM  aaaaaxejm 
uunrnT oamaonjecmT 


or  nrocr 


jwalyaio  raport  oa  pneadur*  MPm^nRTTJ 


TOXUvUnS 


VOlua 

7 

1 


ooalyala  xaport  on  prooadara  tOfm._lwrotJSSas.l*CWiJa 


Tam._LXRU 


vaxua 

1 

0 


or  MBLnn  mroitr 


Hgure  30-21  contimwd:  ATI  Static  Analysis  of  BUFFER  Package 


-•  with  Mcnatjamnjawti 
with  ■avfni_x»or_MKM; 

UM  BOrm.XOTOr.HNI; 

--  with  any  hafannoad  Vaekagaa: 
with  DwmncaB,  ranaa-i 
uaa  oirunTiaB,  fonwr; 

•  •  Taat  aeript  xaquiraa  tha  uaa  o<  tha  jail_CaMMDB  and  JUBavSIS  packagaa: 

uaa  hBhIUI_BhmU_OQMMnS  I 
with  jiniaisT_aMdBU_aahuaxs  « 
uaa  jiiaxnT~ahanMlMnLni«  < 


--  on*  MUR 


pxooadura  IIRjnRn  ia 

..  inatantiatieoa  ot  aaaarie_Chaeka  if  naadad: 

--  Daelara  work  wariablaa: 
naOLT  ;  CP.fOaHMT; 

bagin 

anar.acuR  (  •TtR.BDrvaa* ,  •aonjaua*  ) 
xRTX»uaa_MBa.Yaia  7 
an.nuci  (  aMca.rou.  )  < 
mtajoanum  ; 

OOMBR  (  'A  aariaa  of  taata  to  ohaek  handling  of  PlfO  quaua*  )  j 


••  nn  ma«8 


TiR  caaa  i 


utKKtjnn  (1)1 

••  OOMBir  (  •Baquaua  iat  itaa:  AAAAA*  )  i 

aaacDR  (  •aoma.iCTin'jnaa.aDma.aHoaaaB’, 

•*. 

ncaRi<ai_aoT_*ifac«p  i  < 

bagin 

dalay  3.0; 

BamA_nvaT jaw . aauuBua  a  ■>  'AhAiiA'); 

dalay  i.O;  --  Allow  prooaaaing  to  ha  parfocaad 

aaeaption 
whan  othara  •> 

maoAL.aacaRiw  (  •othara*  ) 
and  ; 

nw  , 


Figure  30-22.  ATA  Test  Script  for  Coverage  and  Trace  Analysis  of  BUFFER  Pack¬ 
age 
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nar  can  a 


aTMtrjmr  <  a  )  ,- 

--  OeMBir  (  •■nquMM  and  Itam:  nBM*  )  ; 

Micuw  I  ••amii_imiT_MSM.K>ma.Bigani’, 

■  ■ 

BEcimoH^w^BxracnD  >  ; 

baylB 

dal*/  a.O;  _ 

■orRR.nm.MMa . nuusua  (i  •>  •aaaaa*); 
d*l«y  I.O;  --  Allov  prooMiag  to  bo  parfenod 

axoaptioo 
ahan  ottaara  ■> 

iiLnkL_axcBaTiap  (  *otbara*  i 
and  t 

atm  ; 

BB.nar  ; 


smajan  (  a  )  ; 

(  ‘Oaquatia  lat  quauad  itaa:  AMM*  )  ; 


Biacim  (  •Bapfait_i»oT_iiaaa.BaFm.DBoaioa*, 

WDOK9nOH_KftJOnCTED  I  / 


bapin 

dalay  3.0> 
aoma.iw 
dolay  a.O; 


.■aaa.nnnami  (  aaaour  >; 

'•  Alloa  pKoeaaaiag  to  ba 


aaoaptlon 
abao  otbora  «> 

JUMAb.BXCafnOH  (  •Otbaro*  )  ; 
and  ; 


oBcx  ('uaguwitp  anioB’,  aaaDur, 


laar  CAaa  a 


atART  nar  ( 


4  ) 

:  ( 


'Ba^piaua  3ad  qoauod 


■aMFnaijK>r_macTiD  i 


Hgure  30*22  contlntied:  ATA  Test  Script  tor  Coverage  and  Trace  Analysis  of  BUFFER 

Package 


0 


# 
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ba«ia 

daisy  3.0; 

■ormt.avarjnas.oiaDiDB  (  ataoLT 

daisy  1.0;  --  Alloa  proeassing  co  ba  parforaad 

aaeaption 
ahao  otbars  •> 

lunaL.ixcimai  (  ’Otnars*  ) 
and  : 

OCM  ; 

OBCK  (•naaoran  OMJtm*.  aiaoLT,  •nass'i; 


arop.oowmMn  ; 


-•  Osa  JOA  dixaetlaaa  to  ehaek  and  catrlaaa  aaalyais  iatoznatlon 

cam  jwLysia  (•aama_xaf(irjan>.aopy8a*. 

imaiaiaTjninaini' 

100.00,  100.01)  ; 

coca  Aasuraia  (•aoraa  xaanjaas.aoma*, 
•oaczazoit.oavaaAaa* , 

00.00,  100.00)  ; 

aafOKr.Aasuraxo  (•anma.iatar.MBaB.Boma',  •all*); 
RaaaTjinusia  ; 


-•  Cboaa  acazpT 


BnD_acairr  ; 
and  TBaT^aOfflK  ] 

Rgure  30-22  continued:  ATA  Test  Script  for  Coverage  and  Trace  Analysis  of  BUFFER 

Package 
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im  II  iiiiiiiiii  II  III! 


MbTUT  HuwMa  (ei  2Mi  Zttfacaaetsii  Pxooaaaiag  Ltd,  l>»0-93 

varaioa  1.1 

Lieaaaa  Ho:  SPUail  (laatltuta  o<  Dafaaea  Aaalyaaal 


Taat  aaaulea  for  ;  TUT^MPPas 

Syataai  Cenfigurad  fox  :  SOMljnnZ 
Taat  Run  on  3*  MW  1*31  at  10:4<:15 


XRTULXUJUnkLPSXfl  :  MK.yaiS  noda  :  TKRCI.OPP  ; 
anjiMioi:  Tna.poix  , 
soKtjaanumi  majnu,  : 

••  A  aaxlaa  of  taata  to  ehaek  hantlUng  of  PlPO  quaua 
. . T*St  1 . 


■i^aetad  Calla  > 

■  ■ 

■jBoaptlan_Mot_bpactad 


taak  BOPPn.XRFOrjMSOS.KIPPn  ; 

Lina  33  i 

Liao  13  ;  nhilo*10op  ;  Top-Of-Loop  i 
Lina  40  ; 

;  proeaduxa  BnppiR_tWOr_iaQS  ■  MtfaiUl  ; 

;  Lina  TS  ; 

taak  BOPPiR.moTjaos.npfn  ; 

Lina  42  ; 

Lina  43  :  if  :  TROB  i 

Lina  41  ; 

Lina  44  ; 

Lina  4C  !  if  :  TltDB  i 

Lina  47  ; 

Lina  4*  ; 

Lina  43  i 

Lina  SI  s  taak*a-aeoapt  ; 

:  pxoeadura  M]PPBR_Z»OT_MSOS.aMOOBDB  < 

:  Lina  77  :  aalact'call  ; 

taak  ■apPBR_X«PIIT_iaa8.KIPP«R  > 

Lina  13  ;  ahila-loep  :  Botton>Of 'Loop  ; 

Lina  13  :  alilla*laap  :  Top-Of-Loop  i 

Lina  40  i 

DOM:  ■OPPBB_IPPOT_IBag.lUPPlR.«aora  ; 

IBB)  TBBT  X 

aorjBomMK  ; 
awrjtMCE:  nuatjorw  ,• 

STMa_oovinai:  twcbjopp  i 

. - . TtPT  3 . 


Figure  30-23.  ATA  Results  for  Coverage  and  Trace  Analysis  of  BUFFER  Package 


■ncoR;  ■avm_n0iiT_MM*.Mim».nQmKnt  , 

■ivaetad  Cklla  • 

■  M 

■xo*pclaB_Mat_|]V*et«d  ; 

DOME:  warmjumnjuaa.wawm.UKHtm  > 


mcDR;  Kirm.xtipaTjHMa .wma.uaguioi  , 

ii^et^  Calls  ■ 

•  • 

■iteaptiaa_Hat_Bavact«d  : 

DOB:  ■cms_mor_Maas.BiimR.oicoBcs  > 
cncK  (  oaoDBOiD  vauii  )  ;»msid 

ItM  'AMM* 

.  OB  TMT  J . 

. TMT  4  . 
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Figure  30>23  coittliHMd:  ATA  Results  for  Coverage  and  Trace  Analysis  of 

BUFFER  Package 
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31.  METRIC 


* 


METRIC  is  the  newest  member  of  Software  Research’s  Software  Testworks  (STW) 
toolset  (see  IDA  Paper-2769,  pp.  25-1  to  25-35).  It  provides  static  code  analysis  and  is 
intended  to  support  maintenance  activities  by  computing  several  complexity  metrics. 
METRIC  supports  two  of  the  most  popular  families  of  metrics:  Software  Science  and 
Cyclomatic  Complexity. 

31.1  Tool  Overview 

METRIC  was  developed  by  Software  Research  who  have  extensive  experience  in 
the  development  and  marketing  of  software  testing  tools.  It  was  first  added  to  STW  in  1993, 
and  STW  has  over  3,5(X)  licenses  to  more  than  1,5(X)  addresses  woildwide.  METRIC  is  a 
language-independent  tool  supported  by  translators  for  Ada,  C,  C+-4-,  and  Fortran.  The 
examination  was  performed  on  METRIC  version  2.10  running  on  a  Sun  SPARC  Station. 
At  the  time  of  examination,  the  price  for  METRIC  as  a  stand-alone  product  started  at 
$4,000,  but  when  bundled  with  other  STW  components  this  jaice  drops  to  as  low  as  $775 
a  copy. 

METRIC  operates  through  a  graphical  user  interface  that  employs  pull-down 
menus.  Once  invoked,  the  user  starts  by  specifying  the  file(s)  to  be  analyzed.  This  is  done 
by  selecting  either  the  Load  Single  File  option  and  then  choosing  the  appropriate  file  from 
the  file  selection  dialog  box  that  pops  up,  or  by  selecting  the  Load  Multiple  Files  option  and 
identifying  the  set  of  files  to  be  processed.  (The  set  of  files  can  be  identified  by  a  pattern 
match,  by  highlighting  each  file  separately,  or  by  specifying  the  selection  of  all  files  shown 
on  the  file  selection  menu.)  Once  the  user  specifies  that  processing  should  continue,  the 
files(s)  are  automatically  aiudyzed  to  determine  their  complexify. 

The  analysis  generates  a  Complexify  Repcmt  and  a  new  window  is  automaticaUy 
created  to  present  this  report  The  types  of  information  included  in  the  report  are  deter¬ 
mined  according  to  a  set  of  predefined  default  values.  Essentially,  the  Complexify  Report 
lists  the  encountered  program  units  (in  their  order  of  occurrence)  and  the  Software  Science 
and  Cyclomatic  Complexify  measures  for  each.  In  order  to  help  determine  the  most  com- 
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plex  program  units,  METRIC  allows  the  user  to  specify  ordering  the  presentation  of  the 
units  in  terms  of  ascending/descending  value  of  any  of  17  complexity  measures.  (Special 
symbols  in  front  of  a  program  unit  name  are  used  to  indicate  a  task  or  package.) 


Additional  textual  reports  are  available  through  one  of  the  menus.  A  Summary 
Report  presents  an  accumulated  account  of  the  complexity  measure  for  the  entire  source 
code  analyzed.  An  Exception  Report  identifies  those  program  units  that  violate  predefined 
maximum  complexity  values.  A  Generic  Report  lists,  for  each  encountered  generic  unit,  the 
generic  name,  the  number  of  times  it  is  instantiated,  and  the  names  of  instantiating  units. 
Two  special  reports  are  provided  for  packages.  The  first  of  these  identifies  packages  that 
violate  predefined  complexity  standards.  The  second  provides  an  intermediate  summary 
report  at  the  package  level. 

In  addition  to  this  textual  reporting,  METRIC  offers  kiviat  diagrams  as  a  graphical 
means  to  view  the  effect  of  applying  multiple  metrics  to  the  source  code.  Three  types  of 
kiviat  diagrams  are  available,  each  providing  an  increasing  number  of  metrics  to  offer  more 
detailed  insights  into  the  software.  Each  of  these  kiviat  diagrams  represents  information 
presented  in  the  Summary  Report  If  desired,  users  can  also  define  their  own  diagrams  to 
display  selected  metric  values. 

METRIC  supports  some  tailorability  through  a  special  menu  provided  for  setting 
threshold  values.  Further  tailoring  is  achieved  by  editing  the  configuration  file;  this  allows 
changing,  for  example,  the  default  page  length  and  the  required  minimum  and  maximum 
estimated  lengths  of  Ada  packages. 

METRIC  also  can  be  operated  in  comnumd  line  mode.  In  this  case,  the  user  simply 
enters  the  METRIC  command  optionally  followed  by  a  series  of  cations  that  determine  the 
types  of  textual  output  reports  that  are  required.  A  separate  command  is  provided  for  pro¬ 
ducing  graphical  kiviat  diagrams  of  the  generated  results. 

31^  Observations 

Ease  of  use.  METRIC  is  very  easy  to  use,  requiring  no  special  knowledge  on  the 
part  of  the  user.  Help  boxes  are  available,  although  these  only  offer  relatively  high-level 
information  on  various  options.  An  Error  Report  is  automatically  produced  if  errors  are 
encountered  during  processing  and  analysis.  This  report  provides  infomiation  that  is  help¬ 
ful  in  correcting  the  error  situation. 


# 
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Documentation  and  user  support.  As  always,  Software  Research’s  documenta¬ 
tion  is  extensive  and  very  useful.  In  this  case,  the  documentation  includes  discussions  on 
the  development  of  complexity  measures,  the  use  of  metrics  to  support  both  development 
and  nuuntenance  activities,  and  a  few  words  on  the  advisability  of  tuning  metrics  based  on 
historical  data. 

Ada  restrictions.  METRIC  supports  the  fuU  Ada  language. 

Problems  encountered.  No  problems  were  encountered  in  the  use  of  METRIC. 

313  Sample  Outputs 

Figures  31-1  through  31-6  provide  sample  outputs  from  METRIC  on  the  Ada  Lex¬ 
ical  Analyzer  Generator  example. 
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Figure  31-1.  METRIC  Kiviat  Chart  Definitions 
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Figure  31-4.  METRIC  Complexity  Summary  Report  for  LL.COMPILE 
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Figure  31-6.  METRIC  Exception  Report  for  LL_COM- 

PE.E 
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32.  McCabe  Tools 


The  Batdeinap  Analysis  Tool  (BAT),  Analysis  of  Complexity  Tool  (ACT), 
McCabe  InstrumentatitHi  Tool,  SLICE,  and  CodeBreaker  support  the  McCabe  Structured 
Testing  methodology  documented  in  NIST  Publicadtm  S(X)-99  [NIST  1982].  BAT  supports 
examining  software  structure  at  both  the  program  and  module  levels,  it  reports  on  software 
complexity,  generates  call  graphs  and  flowgraq;>hs,  and  identifies  needed  test  paths.  BAT 
also  provides  support  for  object-cniented  applkaticms  via  a  Class  Editor  which  allows  the 
user  to  group  modules  together  into  a  class  and  dim  name  it  ACT  imivides  a  subset  of  the 
BAT  functirmality  focusing  <m  module  level  analysis.  The  McCabe  Instnimentatitm  Tool 
supports  coverage  analysis.  SLICE  is  a  data-driven  software  visualizatitm  tool  that  allows 
the  user  to  examine  the  last  executitm  path  takm  through  a  progrant  CodeBreaker  com¬ 
pares  the  structure  of  modules  or  programs  to  aid  in  the  identificatimi  of  reusable  and  redun¬ 
dant  code,  the  locating  of  a  particular  module  within  a  large  system,  or  identifying  the  scope 
of  needed  regressicm  testing.  It  also  compares  program  inqilementatitni  with  design. 

Additional  tools,  not  examined  here,  are  START,  McC^abe  (X>  Tool,  CaseBridge 
and  BattlePlan.  START  analyzes  Data  Flow  Diagrams  (DFDs)  to  compute  requirements 
complexity,  identifies  DFD  components  which  may  run  asynchronously,  and  identifies  end- 
to-end-scenarios,  bodi  in  terms  of  test  conditions  necessary  to  drive  each  data  flow  scenario 
aiul  in  terms  of  data  flows  for  acceptance  testing.  McCabe  OO  Tool  provide  static  and 
dynamic  analysis  for  object-oriented  designed  software.  CaseBridge  provides  botii  forward 
and  reverse  engineering  interfaces  between  BAT  and  the  StP  and  Teamwcnk  CASE  sys¬ 
tems.  BattlePlan  is  a  new  tool;  it  is  a  fincmt-end  CASE  tool  that  allows  users  to  design  new 
applicatitms  and  incorporate  new  functions  into  a  system  witiun  the  firamew«k  of  reverse 
engineering.  The  Inference  Engine,  a  BAT  option,  provides  a  query  language  intended  to 
help  a  user  identify  where  a  design  needs  to  be  improved;  this  optitm  was  not  examined. 

McCabe  Structured  Testing  is  based  (m  the  cyclomatic  complexity  metric.  This 
metric  has  been  the  subject  of  several  evaluatitms.  In  1988,  the  Air  F6ice  Electronic  Sys¬ 
tems  Division  (ESD)  adqned  the  measurement  and  control  of  cyclomatic  complexity  tm  all 
of  its  contracts. 
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32.1  Tool  Overview 

The  McCabe  tools  were  developed  by  McCabe  &  Associates.  This  oiganization 
supports  a  user  group  and  provides  a  newsletter  and  hot-line  support  to  tool  users.  Training 
seminars  and  consultancy  services  are  also  available.  Most  of  the  McCabe  tools  suf^rt 
over  a  dozen  languages  and  over  two  dozen  dialects,  including  Ada,  C,  C++,  Cobol,  Pascal, 
Fortran,  and  PL/1.  The  recently  introduced  McCabe  Instrumentation  Tool,  howevo-,  cur¬ 
rently  only  supports  Ada,  C,  C++,  Cobol,  and  Fortran.  The  tools  also  support  Caine,  Faber, 
and  Gordon  FDL  and  those  PDLs  employed  by  StP  and  Teamwork.  The  tools  are  available 
on  a  wide  range  of  platforms,  including  Sun,  Apollo,  HP,  and  NCR  Tower  woritstations 
under  Unix,  DEC  VMS  and  Ultrix  systems,  and  the  IBM  PC  under  DOS.  They  use  OSF/ 
Motif  and  OpenWindows  as  appropriate. 

The  tools  are  packaged  in  various  ways.  ACT,  CodeBreaker,  and  the  Instrumenta¬ 
tion  Tool  can  be  invoked  via  the  graphical  McCabe  Menu-Driven  User  Interface.  BAT  has 
its  own  graphical  user  interface;  with  the  approiniate  licenses,  CodeBreaker,  the  Instrumen¬ 
tation  Tool,  and  SLICE  can  be  invoked  from  the  BAT  interface. 

The  evaluation  was  performed  on  McCabe  tools  version  V19920601-1  13  CTS  run¬ 
ning  on  a  Sun  SPARCstation  under  Unix  with  OpenV^dows.  At  the  time  of  evaluation, 
the  price  for  ACT  started  at  $11,S(X)  and  the  price  for  BAT  at  $21,500.  Other  tools  are  pur¬ 
chased  in  addition  to  BAT  and  the  price  for  CodeBreaker  started  at  $5,000;  the  price  for  the 
McCabe  Instrumentation  Tool  and  SLICE,  togedier,  started  at  $5,000.  McCabe  &  Associ¬ 
ates  will  provide  prospective  users  with  a  wOTking  example  of  the  users’  own  jvogram. 
Additionally,  demonstration  discs  for  ACT  are  currently  available,  and  expected  to  become 
available  for  the  McCabe  Instrumentation  Tool  in  the  near  future. 

Some  aspects  of  tool  usage  are  common  to  all  of  the  McCabe  tools.  All  Ada  source 
programs  must  be  parsed  befme  the  tools  can  be  run.  Several  different  parsers  are  available 
for  Ada  source  code,  the  choice  of  which  to  use  depends  on  the  task  at  hand,  for  example 
instrumentation  or  analyzing  Halstead  metrics.  Each  parser  translates  Ada  source  code  into 
McCabe  intermediate  files.  By  default,  the  parse  library  resides  in  the  current  directory;  the 
user  must  be  careful  when  moving  between  directories  not  to  create  multiple  parse  libraries 
and  also  to  ensure  that  successive  parses  do  not  corrupt  the  parse  library.  While  parsing  in 
correct  compilation  (»der  is  not  necessary  to  use  the  full  capabilities  of  ACT,  it  is  recom¬ 
mended.  Access  to  the  full  capabilities  of  BAT  requires  parsing  in  compilation  order. 
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The  tools  use  two  ccmfiguration  files  to  specify  needed  information.  The  System 
Ctmfiguration  File  defines,  for  example,  the  chart  plotter  driver  and  applicable  parsers.  The 
Program  Configuration  File  defines  the  source  files  that  make  up  each  program. 

Finally,  tool  operation  can  be  modified  via  a  set  of  commands  given  in  an  exclude 
file.  (Although  the  use  of  exclude  files  is  only  available  under  a  BAT  license,  these  special 
files  can  be  used  to  affect  the  ou^ut  of  other  tools  as  well.)  Exclude  files  can  be  used  to 
limit  the  level  of  calls  from  a  module,  exclude  modules  from  analysis,  or  bind  together 
classes  of  similar  modules.  They  can  be  used  via  either  the  graphical  or  command  line  inter¬ 
faces,  or  through  special  entries  in  the  Program  Configuration  File. 

32.1.1  ACT 

The  ACT  has  two  primary  purposes:  examining  the  control  stnictuie  of  a  module 
and  generating  the  set  of  test  paths  needed  for  basis  path  testing.  Basis  path  testing  is  a  form 
of  structured  testing  where  the  minimum  set  of  lineariy  independent  paths  through  a  mod¬ 
ule  are  exercised.  ACT  can  be  applied  to  both  PDL  and  source  code. 

Using  one  of  the  graphical  user  interfaces,  the  user  starts  the  application  of  ACT  by 
identifying  the  program,  file(s),  or  module(s)  of  interest  The  various  options  and  tool  func¬ 
tions  are  then  invoked  via  pull-down  menus.  To  aid  in  the  examination  of  module  control 
structure,  ACT  generates  flowgraphs  that  give  a  graphical  overview  of  the  structure  of  each 
module.  This  special  type  of  directed  graph  uses  different  colors,  or  line  Qrpes  if  color  is  not 
available,  to  distinguish  between  upward  flows,  a  structured  exit  from  a  loop,  and  other 
plain  downward  flowing  edges.  Similarly,  edges  for  loops  or  loop  exits  are  shown  as  curved 
lines,  whereas  most  other  edges  are  straight  lines.  Flowgraphs  are  supported  by  annotated 
source  listings  that  relate  a  graph  back  to  the  source  code.  The  final  capability  provided  in 
this  category  is  the  analysis  of  module  complexity.  ACT  reports  on  complexity  in  terms  of 
McCabe’s  cyclomatic,  essential,  and  module  design  complexity,  and  using  lines  of  code 
and  Halstead’s  metrics. 

ACT  supports  McCabe  Structured  Testing  by  deriving  a  basis  set  of  end-to-end  test 
paths  foramodule.  These  test  paths  can  be  presented  graphically  as  apath  through  the  flow- 
graph  (either  superimposed  on  the  flowgraph  or  showing  test  paths  only)  or  listed  textually 
with  their  corresponding  node  numbers  and  test  omditions.  Some  of  the  generated  paths 
may  be  unrealizable,  for  example,  where  there  are  data  dependencies  between  conditions 
that  prevent  a  condition  from  taking  on  the  values  required  to  execute  its  branches.  ACT 
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also  gives  the  user  the  option  to  define  his  own  set  of  test  paths.  This  capability  allows,  for 
example,  eliminating  unrealizable  paths  from  the  set  of  test  paths  derived. 

32.1,2  BAT 

BAT  extends  the  functionality  of  ACT  is  several  ways;  primarily,  it  extends  the  stat¬ 
ic  analysis  to  address  the  integration  complexity  of  source  code  and  the  generation  of  inte¬ 
gration  test  paths.  The  following  discussion  just  addresses  the  additional  functionality 
provided  by  BAT.  Like  ACT,  BAT  can  be  applied  to  PDL  in  addition  to  source  code. 

On  its  invocation,  BAT  starts  by  presenting  a  Battlemap  display  of  the  program 
under  examination.  The  main  part  of  a  Battlemap  display  is  a  structure  chart  that  graphical¬ 
ly  displays  the  modules  in  a  program,  or  subsystem,  and  the  calling  relationships  between 
these  modules.  The  cyclomatic  and  essential  complexity  of  each  module  can  be  shown  on 
a  Battlemap  using  the  following  symbols: 


Low  cyclomatic  com¬ 
plexity 


□  High  cyclomatic  com¬ 
plexity 

□  High  cyclomatic  com¬ 
plexity 


Alternatively,  on  a  color  monitor,  colors  can  be  used  to  represent  different  con^lex- 
ity  levels.  Special  notations  to  represent  iterative  and  conditional  calls  between  modules  are 
available.  Structure  charts  can  be  drawn  in  foo^rint,  torse,  or  verbose  detail,  essentially  II 

affecting  how  modules  are  identified,  ^fiew  options  allow  adjusting  structure  chart  layout 
and  positioning  within  the  structure  chart;  in  this  last  case,  the  user  can  search  for  a  partic¬ 
ular  module  on  a  large  Battlemap  display  and  the  display  will  automatically  reposition  with 
respect  to  this  module.  A  variety  of  information  can  be  called  up  by  clicking  on  a  module.  • 

This  includes  the  aimotated  source  code  listing,  module  flowgraph,  module  summary,  test 
path  listings,  and  test  path  graphs.  Free-form  messages  or  specifications  pertaining  to  a 
selected  module  and  even,  on  a  Sun  SPARCstation,  audio  notes  to  annotate  a  selected  mod¬ 
ule  can  be  entered  and  retrieved.  By  clicking  on  a  line  between  modules,  the  user  can  # 
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request  a  line  summary  report.  This  gives  the  numbers  of  the  connected  modules,  line  type 
(unconditional,  conditional,  iterative),  and  any  invoked  parameters.  A  Battlemap  display 
can  be  printed  as  a  whole  or  as  a  set  of  subtrees.  The  print  of  the  entire  structure  chart  can 
be  compressed  onto  a  single  page  or  spread  across  several  pages  with  special  switches  con¬ 
trolling  the  use  of  off-page  coimector  symbols.  Other  switches  allow  the  user  to  set  the 
detail  level  and  request  the  display  of  formal  parameters  on  the  printed  structure  chart 

Under  its  graphical  interface,  all  BAT  tools  and  options  are  invoked  from  the  Bat¬ 
tlemap  display  using  pull-down  menus.  In  addition  to  the  cyclomatic  and  design  complex¬ 
ity  analysis  performed  by  ACT,  BAT  also  examines  essential  complexity  at  the  module 
level  to  give  a  feel  for  the  degree  to  which  a  module  contains  unstructured  constructs. 
Cross-referencing  between  modules  is  given  by  listings  of  called-by  and  calls-to  relation¬ 
ships.  Additional  textual  information  supporting  the  Battlemap  display  is  a  context  listing 
showing  where  modules  are  located  and  an  index  listing  that  maps  module  numbers  to 
module  ruimes.  These  listings  can  be  sorted  alphabetically,  numerically,  by  position  on  Bat¬ 
tlemap,  or  by  complexity  value. 

To  aid  in  understanding  the  design  structure  of  a  program,  the  user  can  request  BAT 
to  generate  the  design  subtrees  embodied  in  the  program.  These  subtrees  are  superimposed 
on  the  Battlemap  display  and  the  user  can  stop  forward  and  backward  through  successive 
ones.  Textual  listings  of  subtrees  can  also  be  generated,  in  this  case  giving  the  associated 
end-to-end  test  conditions  for  each  subtree  that  will  support  structured  testing  at  the  inte¬ 
gration  level.  Subtree  graphs  and  text  can  be  generated  at  both  the  design  and  cyclomatic 
complexity  detail  levels. 

BAT  performs  static  analysis  on  the  program  structure  to  report  on  its  design  ■'  '>m- 
plexity  and  integration  complexity.  Both  these  metrics  are  based  on  module  design  com¬ 
plexity  and  take  account  of  the  program’s  architecture.  Branch  count  metrics  report  on  die 
number  of  branches  contained  in  each  module.  In  addition  to  textual  listings,  graphical  rep¬ 
resentations  of  the  McCabe  and  Halstead  metrics  are  available.  These  graphical  represen¬ 
tations  are  a  histogram,  scatterplot,  or  kiviat  diagram  where  the  user  can  portray  selected 
default  metrics  or  choose  from  a  menu  of  the  full  set  of  McCabe  and  Halstead  metrics.  The 
user  can  also  change  the  threshold  values  assigned  to  chosen  metrics. 


32.U  McCabe  Instrumentation  Tool 

The  McCabe  Instrumentation  Tool  works  with  either  ACT,  for  structural  coverage 
analysis  at  the  unit  level,  or  BAT,  to  support  coverage  analysis  at  both  unit  and  integration 
levels.  Instrumentation  is  simple  and  performed  similarly  under  both  tools.  When  perform¬ 
ing  instrumentation  from  BAT,  for  example,  the  user  only  needs  to  specify  the  destination 
of  the  instrumented  files  (necessary  since  otherwise  original  source  files  will  be  overwrit¬ 
ten),  the  files  to  be  instrumented,  and  the  instrumenting  parser  in  the  Program  Configuration 
File,  and  request  the  export  option.  The  instrumented  files  are  then  generated  and  written 
to  the  specified  directory.  After  the  provided  McCabe  library  of  instrumentation  routines 
has  been  compiled,  the  instrumented  files  are  compiled  and  linked  as  usual.  When  run,  the 
instrumented  program  creates  a  file  of  trace  data  which  is  subsequently  imported  back  to 
the  BAT  environment  for  analysis.  BAT  maintains  a  data  base  of  test  results  so  the  results 
of  successive  test  runs  can  be  accumulated  for  cumulative  coverage  reporting. 

Coverage  information  is  available  textually  and,  using  the  capabilities  of  either 
ACT  or  BAT  as  appropriate,  graphically  to  jn'ovide  a  visual  representatitni  of  test  effective¬ 
ness.  At  the  module  level,  the  tool  reports  on  the  tested,  untested,  and  partially  tested  basis 
paths.  Tested  and  untested  paths  can  be  listed  textually  or  graphically  by,  for  example, 
superimposing  paths  on  the  module  flowgraph.  A  branch  coverage  report  shows  the  number 
of  branches,  the  number  tested,  and  the  percent  of  branches  tested  for  each  module.  In  this 
case  the  graphical  equivalent  is  an  edge  coverage  graph  which  is  a  subset  of  the  full  module 
flowgraph  (edges  that  do  not  lie  on  a  tested  path  are  omitted)  and  which  gives  a  visual  over¬ 
view  of  unit  test  coverage.  Finally,  the  actual  complexity  is  compared  to  cyclomatic  com¬ 
plexity  to  give  a  module  testedness  report  that  can  be  used  to  identify  modules  requiring 
additional  attention. 

Similar  types  of  information  are  provided  at  the  integration  level,  but  here  reports 
address  tested,  untested,  and  partially  tested  subtrees.  Again,  information  is  available  both 
textually  and  graphically  (this  time  superimposed  on  the  Battlemap  display).  TWo  new  met¬ 
rics  are  used  to  relate  achieved  coverage  to  desired  coverage.  The  design  testedness  metric 
provides  an  overview  of  the  testedness  of  the  entire  program,  whereas  the  integration  com¬ 
plexity  metric  summarizes  the  number  of  subtrees  at  the  design  detail  level. 
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32.1.4  SLICE 


A  software  slice  is  defined  as  the  set  of  code  touched  by  one  execution  trace  duough 
a  program.  Visualization  of  a  slice  is  useful  in,  for  example,  debugging  to  identify  where  a 
bug  is  located  and  the  path  and  code  associated  with  the  bug.  It  can  also  be  used  to  aid  in 
establishing  the  traceability  between  requirements  and  physical  code  by  picking  test  data 
that  is  representative  of  a  particular  functional  requirements  and  obtaining  the  correspond¬ 
ing  execution  slice. 

The  SLICE  tool  determines  slices  dynamically  as  a  program  executes  with  chosen 
test  data.  It  requires  both  BAT  and  the  McCabe  Instrumentation  Tool.  First  the  program  is 
instrumented  to  produce  a  trace  file,  executed  with  sample  data  and  the  trace  file  inqxnrted 
back  into  BAT  as  discussed  previously.  The  user  then  can  access  SLICE  data  in  one  of  two 
ways.  To  request  SLICE  information  for  a  single  module,  the  user  can  click  on  that  module 
on  the  Battlemap.  BAT  then  displays  the  slice  of  code  that  was  traversed  during  that  mod¬ 
ule’s  execution.  The  slice  is  shown  both  graphically  and  textually.  For  the  graphical  view, 
the  module’s  edge  coverage  graph  is  shown  with  the  edges  that  were  traversed  during  exe¬ 
cution  being  denoted  by  a  solid  line.  The  textual  view  is  presented  alongside  with  the  exe¬ 
cuted  path  through  the  associated  source  code  highlighted. 

To  view  slice  information  for  the  program  as  a  whole,  or  for  several  modules,  the 
user  switches  to  the  instrumentation  mode  within  BAT;  this  causes  the  SLICE  options  dia¬ 
log  box  to  be  displayed.  Here,  again,  information  is  presented  both  graphically  and  textu¬ 
ally.  In  this  case,  however,  the  edge  coverage  graph  and  associated  text  is  presented  for  each 
module  in  turn,  in  the  order  that  the  modules  were  executed.  The  user  can  step  forward  or 
backward  through  the  set  of  traversed  modules.  Other  SLICE  options  allow  tlw  highlighted 
text  and  edge  coverage  graph  to  be  printed. 

32.1.5  CodeBreaker 

CodeBreaker  is  primarily  used  to  compare  the  structure  of  two  modules  or  two  pro¬ 
grams.  This  is  used  for  purposes  such  as  verifying  that  the  restructured  version  of  a  module 
preserves  both  the  decision  structure  and  the  calling  structure  of  the  original,  comparing  an 
original  and  modified  module  to  determine  the  design  paths  that  need  regression  testing, 
and  aiding  in  the  identification  of  likely  candidates  for  further  examination  as  possible 
redundant  or  reusable  modules. 
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The  user  can  request  the  comparison  of  modules  contained  in  either  two  specified 
files  or  two  specified  programs.  CodeBieaker  then  compares  the  designs  of  the  selected 
modules.  It  does  this  by  generating  a  basis  set  of  expanded  or  design-reduced  paths  through 
the  first  module  and  examining  each  corresponding  path  through  the  second  module  for 
matches  or  mismatches.  The  user  can  set  switches  that  control  what  the  tool  classes  as  a 
mismatch;  these  switches  cause  CodeBieaker  to  ignore  condition  names,  module  names,  or 
module  calls.  An  additional  switch  specifies  that  attempts  should  be  made  to  match  the  sec¬ 
ondary  module  to  any  subgraph  of  the  primary  module.  To  aid  in  identifying  likely  candi¬ 
dates  for  comparison,  the  user  can  also  request  a  list  of  the  modules  in  two  programs  sorted 
by  the  weighted  sums  of  their  complexity  metrics. 

Program  comparison  is  performed  in  a  similar  maimer.  Here  CodeBreaker  gener¬ 
ates  a  basis  set  of  integration  paths  through  the  first  program  and  attempts  to  find  a  corre¬ 
sponding  subtree  through  the  second  program  that  “matches”  each  of  these  paths.  Again  the 
user  can  request  that  module  calls,  modules  names,  and  condition  names  be  ignored.  In  this 
case,  an  additional  switch  allows  the  user  to  specify  the  required  level  of  comparison  in 
terms  of  module  invocation  depth. 

For  both  module  and  program  comparison,  the  ouq>ut  depends  on  the  choice  of 
which  object  is  treated  as  the  primary  object  and  which  the  secondary.  For  complete  com¬ 
parison  results,  each  object  should  be  examined  in  both  roles. 

32,2  Observations 

Ease  of  use.  Most  of  the  tools  have  a  graphical  menu-driven  interface  for  use  with 
windows  and  a  command-driven  interface  for  use  when  windowing  is  not  available.  In  all 
cases,  the  interfaces  offer  consistent  usage;  for  example,  if  no  program  name  is  given  for  a 
tool  invocation,  the  default  is  taken  firom  the  Program  Configuration  File.  The  graphical 
interfaces  are  uniformly  easy  to  use.  While  not  actually  difficult  to  use,  the  command  line 
interface  can  require  the  user  to  give  many  arguments  to  invoke  full  tool  flexibility  and 
power.  This  interface  helps  the  user  by  allowing  him  to  request  information  on  the  argu¬ 
ments  available  with  each  command  type. 

Minor  tailorability  is  allowed  through  the  use  of  the  system .  def  file.  This  file  is 
used  to  specify  editor,  parser,  printer,  and  plotter  information.  It  also  provides  for  custom¬ 
ization  of  font  format,  graph  layout  and  notation,  use  of  colors,  threshold  values  for  various 
metrics,  and  special  options  for  some  tools.  In  addition,  special  environment  variables 

I 


120 


allow,  fOT  example,  specifying  a  diiectcny  for  die  parse  library  to  reside  in.  Users  can  have 
their  own  versirm  of  the  system .  de f  file. 

In  addition  to  supporting  flow  drivers  for  HPGL  plotters,  HP  Laseijet  compatible 
output  for  Unix  and  DOS,  Postscript  output,  and  scrn  for  DOS,  these  tools  also  support  a 
zoomflow  driver  that  generates  output  for  X> Windows  and  OpenLook  users,  allowing  the 
user  to  enlarge  or  reduce  flowgraphs  presented  on  the  screen. 

Documentation  and  user  support.  The  tools  are  supported  with  extensive  docu¬ 
mentation.  In  a  couple  of  cases,  the  documentation  did  not  exactly  match  tool  operation, 
but  these  slight  deviations  caused  Uttle  difficultly.  McCabe  &  Associates  was  very  helpful 
and  prompt  in  answering  any  questions  that  arose. 

Instrumentation  Overhead.  The  user  can  limit  the  amount  of  instrumentation  per¬ 
formed  by  explicitly  identifying  the  files  to  instrumenL  Additioiudly,  using  the  command 
line  interface,  the  user  can  specify  which  modules  within  a  file  to  instrument  Full  instru¬ 
mentation  of  the  Ada  Lexical  Analyzer  Generator  gave  an  increase  in  source  code  size  of 
28%  and  an  increase  in  object  code  size  of  15%. 

Ada  restrictions.  These  tools  do  not  handle  concurrent  Ada  programs.  Tasks  are 
treated  as  sequential  subprograms.  Specifically,  the  select  statement  is  treated  similar  to  a 
case  statement  accept  and  abort  statements  are  ignored,  a  terminate  alternative  is  treated 
as  a  return  statement  and  a  remote  procedure  call  referring  to  an  entry  declared  in  another 
task  (r)  is  translated  to  a  call  to  the  task  (r)  itself.  The  Ada  parser  ignores  exceptions  that 
can  be  raised  implicitly  by  means  of  exceptirm  propagation.  An  explicit  raise  statement  is 
always  translated  to  a  return  statement  regardless  of  whether  a  handler  is  associated  with 
the  exception.  For  convenience,  all  handlers  attached  to  the  end  of  a  frame  are  grouped 
together  like  a  case  statement  and  treated  as  a  separate  nmdule.  Extended  names  are  not 
used  and  the  parser  differentiates  between  overloaded  or  redeclared  module  names  by 
assigning  version  numbers  to  module  nam«  in  the  order  of  their  arrival  to  the  parser.  Since 
the  parser  does  not  remember  the  types  and  object  declarations  in  programs,  it  is  not  able 
to  perform  overload  resolution  when  parsing  a  subprogram  invocation  that  referred  to  an 
overloaded  subprogram  name.  Instead,  it  chooses  arbitrarily  from  among  the  module 
names  that  correspond  to  the  overloaded  subprograms.  This  may  result  in  inaccuracies  in 
the  BAT  outputs. 

Problems  encountered.  No  problems  were  encountered  in  tool  operation. 
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Sample  Outputs 

Figures  32-1  through  32-40  provide  sample  outputs  from  ^fcCabe  tools. 
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Annoc«t«d  Source  Liecing 


Program:  ll.ecmipile 

File:  /eval/mccabe/viork/ll_caaipile.a 

Language:  inet_ada  Date/Tiine:12/28/92  14:01:23 


Module 

Latter 

• 

II 

v(0) 

av(G) 

iv(C) 

Start 

Line 

Hum  of 
Line* 

A 

llflnd 

5 

4 

1 

145 

19 

B 

llprtatrlng 

3 

3 

2 

168 

8 

C 

llprt token 

2 

1 

2 

180 

9 

D 

llaklptoken 

1 

1 

1 

193 

9 

B 

llakipnode 

1 

1 

1 

206 

10 

F 

llskipboch 

1 

1 

1 

222 

11 

0 

llfatal 

1 

1 

1 

237 

8 

H 

get.charaeter 

3 

1 

3 

251 

12 

1 

cvt.atring 

3 

1 

1 

275 

10 

J 

■ake.token 

11 

1 

7 

286 

39 

K 

llnaxttokan 

2 

1 

1 

340 

8 

L 

bulldright 

10 

4 

9 

394 

54 

M 

fauildaelecC 

2 

1 

2 

453 

8 

N 

readgram 

6 

1 

5 

463 

35 

0 

3 

3 

1 

508 

13 

P 

match 

4 

4 

1 

538 

14 

Q 

expand; 1 

8 

1 

3 

554 

38 

R 

aynchrenlte 

9 

4 

5 

602 

49 

S 

teatsyneh 

3 

1 

2 

653 

12 

T 

pars* 

11 

1 

9 

667 

52 

U 

llmaln 

1 

1 

1 

721 

4 

V 

ll.cemplle 

1 

1 

1 

727 

3 

141 

function  LLFIMD(  ITOt:  LLSTRZNCS;  WHICH;  LLSTYLB  )  return  IMTECER 

142 

--  Find  item  in  aymbol  table  —  return  index  or  0  if  not  found 

143 

—  Asaumes  aymbol  table  ie  aortad  in  aacending  order. 

144 

LOW,  MIDPOINT.  HIGH:  INTBQER; 

145 

AO 

begin 

146 

A1 

LOW  :«  1; 

147 

A2 

HIGH  LLTABLBSXZC  »  1; 

148 

A3  A4 

while  LOW  HIGH  loop 

149 

AS 

MIDPOINT  (HIGH  «  LOW)  /  2; 

ISO 

A6 

if  ITB(  <  LLSYM80LTABLE (MIDPOINT)  .XSY  then 

151 

A7 

HIGH  KIDPOINT; 

1S2 

A8 

alaif  ITBf  >  LLSYMBOLTABLB (MIDPOINT) .XHY  then 

1S3 

A9 

it  LLSyMBOLTABLE(MIDPOINT) .KIND  >  WHICH  then 

1S4 

AlO 

return  (  MIDPOINT  ); 

ISS 

elae 

1S6 

All 

return (  0  ) ; 

157 

A12 

end  if; 

158 

elae  —  ITB(  >  LLSyMBOLTABLB(MIDPOINT) .KEY 

159 

A13 

LOW  1-  MIDPOINT  *  1; 

160 

A14 

end  if; 

161 

A15 

end  loop; 

162 

A16 

return (  0  ):  —  item  ia  not  in  table 

163 

A17 

end  LLFIND; 

Figure  32-1.  ACT  Annotated  Listing  for  Function  LLFIND 
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Figure  32-2.  ACT  Graph  for  LLFIND 
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MBIKICS  for  PROCXAM  ll_c<»pil* 


Mod  •  MODOLB 

v(C> 
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iv(0) 
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5 

4 

1 

19 
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3 

3 

2 

8 
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39  llprttokM 

2 

1 

2 

9 
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1 

1 

9 
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1 

1 

1 

10 

206 
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1 

1 

1 

11 
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1 

1 

1 

8 

237 
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3 

1 

3 

12 

251 

9  evt.striaa 

3 

1 

1 

10 
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11 

1 

7 

39 
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2 

1 

1 

8 
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10 

4 

9 

54 

394 

14  buildsalocc 

2 

1 

2 

8 

453 
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6 

1 

5 

35 

463 

18  •ras* 

3 

3 

1 

13 
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a  match 

4 

4 

1 

14 

538 

2  axpaad;! 

8 

1 

3 

38 
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9 

4 

5 

49 

602 

16  taatayneh 

3 

1 

2 

12 

653 

11  paraa 

11 

1 

9 

52 

667 

7  llamin 

1 

1 

1 

4 

721 

1  ll.eonpila 

1 

1 

1 

3 

727 

57  gat.ehar 

3 

1 

3 

11 

57 

51  char.adwaneo 

3 

1 

3 

15 

70 

S3  look..ahaad 

1 

1 

1 

5 

87 

41  naxt_eharaetar 

3 

1 

3 

21 

94 

42  naxt.ldoncxfiat 

4 

1 

3 

18 

118 

43  naxt_apac_«yai 

10 

1 

10 

38 

138 

40  naxt.atring 

4 

3 

2 

17 

179 

36  advance 

8 

4 

8 

31 

197 

72  «arg«_xangoa 

2 

1 

1 

6 

107 

70  altaraata 

14 

9 

6 

54 

114 

34  char^ranga 

3 

1 

1 

13 

175 

58  raatrict 

14 

1 

8 

65 

219 

59  tail 

11 

4 

5 

63 

290 

54  raaolva.aabiguity 

15 

9 

12 

98 

363 

44  caaplata_alt 

8 

1 

5 

40 

462 

65  eo«plata_concat 

8 

1 

5 

40 

507 

67  oomplata^opt 

3 

1 

1 

16 

553 

37  co«plata_pat 

12 

1 

9 

53 

570 

24  c<Mplata_pattarna 

2 

1 

2 

6 
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21  lltakaactlon 

68 

1 

40 

192 

27 

402 

127 

270 

1837 

at  in 

6.28 

1.98 

4.22 

28.7 

NuMb*x  of  ModulM;  64 


Figure  32-3.  ACT  Metrics  Summaiy 
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ProgruD:  ll.cooipila 


Modul*  Nmm 

coda 

cooMnc 

blank 

coda  (r 

llfind 

17 

0 

0 

2 

llprtatring 

6 

0 

0 

0 

llprttokan 

7 

0 

0 

1 

llakiptokan 

7 

0 

0 

0 

llakipBoda 

8 

0 

0 

0 

llaklpboeh 

9 

0 

0 

0 

llfatal 

6 

0 

0 

0 

gat_eharaetar 

10 

0 

0 

0 

evt_atring 

8 

0 

0 

0 

awka.tokan 

37 

0 

0 

0 

llnaxttokan 

6 

0 

0 

0 

tauildrlght 

48 

4 

0 

0 

buildaalaet 

6 

0 

0 

1 

raadgram 

31 

3 

0 

4 

•ras« 

9 

2 

0 

3 

match 

11 

1 

0 

3 

axpand;! 

32 

5 

0 

1 

aynchroniia 

44 

3 

0 

0 

taatayneh 

9 

2 

0 

1 

4S 

6 

0 

4 

llmain 

3 

0 

0 

3 

ll.eoapila 

3 

0 

0 

1 

gat.ehar 

9 

0 

0 

0 

ehar.advanea 

12 

1 

0 

1 
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3 
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0 

0 
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19 

0 

0 

0 
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14 

0 

0 

0 
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3S 

0 

0 

0 

n«xt_acring 

15 

0 

0 

0 
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29 

1 

0 

1 

4 

0 

0 

0 
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SO 
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1 

char_ranga 
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0 

raatrlct 

58 
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1 

tail 

54 
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0 
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raaolva_ambiguity 

92 
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0 

0 

coavlata.alt 

35 

4 

0 

1 

complata.coneat 

36 

2 

0 

0 

caa[pl*ta_opt 

13 

1 

0 

0 

cca[plata_pat 

47 

5 

0 

1 

eoa[plata_pattarna 

4 

0 

0 

0 

eoncatanata 

8 
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0 
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23 
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0 
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21 

3 
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0 
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Figure  32-4.  ACT  Line  Count  Report 
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Prograa:  ll.coapil* 


N  :  Progm  length 
D  :  Program  difficulty 
B  :  Error  aatimata 


V  :  Program  volume 
1  :  Intalligant  content 
T  :  Programming  time 


L  :  Program  level 
E  :  Programming  effort 


Module  Name 

N 

V 

L 

D 

I 

B 

B 

T 

llfind 

74 

459 

0.05 

21.5 

21.4 

9879 

0.15 

548.8 

llprtatring 

37 

193 

0.10 

10.5 

18.4 

3034 

0.06 

112.4 

llprttoken 

43 

226 

0.09 

11.5 

19.7 

3604 

0.08 

144.7 

llskiptoken 

42 

226 

0.08 

12.0 

18.9 

2718 

0.08 

151.0 

llskipnode 

63 

377 

0.06 

17.5 

31.5 

6590 

0.13 

366.1 

llakipboth 

66 

399 

0.05 

18.5 

21.6 

7380 

0.13 

410.0 

llfatal 

38 

199 

0.09 

11.0 

18.1 

2194 

0.07 

121.9 

get.character 

40 

213 

0.09 

11.0 

19.4 

3343 

0.07 

130.1 

cvt_atring 

32 

160 

0.11 

9.0 

17.8 

1440 

0.05 

80.0 

make_tokan 

311 

1629 

0.02 

61.5 

26.5 

100193 

0.54 

5566.3 

llnaxt token 

39 

306 

0.10 

10.5 

19.6 

2164 

0.07 

130.2 

buildright 

351 

2001 

0.01 

67.5 

29.6 

135058 

0.67 

7503.2 

buildaelect 

42 

336 

0.09 

11.5 

19.7 

2604 

0.08 

144.7 

readgram 

176 

1313 

0.02 

48.5 

27.1 

63674 

0.44 

3537.4 

eraaa 

38 

199 

0.10 

10.5 

19.0 

2094 

0.07 

116.3 

match 

47 

261 

0.07 

14.0 

18.6 

3655 

0.09 

203.1 

expand;! 

193 

1456 

0.02 

51.0 

28.6 

74272 

0.49 

4126.2 

synchronize 

250 

1991 

0.01 

71.5 

27.9 

142388 

0.66 

7910.5 

testsynch 

35 

180 

0.10 

10.0 

18.0 

1795 

0.06 

99.7 

parse 

339 

1888 

0.02 

66.5 

28.4 

125572 

0.63 

6976.2 

llmain 

6 

16 

0.50 

2.0 

7.8 

31 

0.01 

1.7 

ll_compile 

3 

5 

1.00 

1.0 

4.8 

5 

0.00 

0.3 

gat.char 

38 

199 

0.10 

10.5 

19.0 

2094 

0.07 

116.3 

char_advanca 

48 

268 

0.08 

13.0 

20.6 

3485 

0.09 

193.6 

look_ahead 

17 

69 

0.22 

4.5 

15.4 

313 

0.02 

17.4 

naxt_charactar 

114 

779 

0.03 

33.0 

23.6 

25705 

0.26 

1428.1 

next_identlfier 

86 

553 

0.04 

35.0 

33.1 

13816 

0.18 

767.6 

naxt_spec_sym 

149 

1076 

0.02 

43.0 

25.0 

46253 

0.36 

2569.6 

next_string 

79 

498 

0.04 

32.5 

22.1 

11205 

0.17 

622.5 

advance 

114 

779 

0.03 

33.0 

23.6 

25705 

0.26 

1428.1 

marga_ranges 

40 

213 

0.09 

11.0 

19.4 

2342 

0.07 

130.1 

alternate 

314 

2605 

0.01 

89.5 

29.1 

233104 

0.87 

12950.2 

char_range 

55 

318 

0.06 

15.5 

30.5 

4929 

0.11 

373.8 

restrict 

389 

2363 

0.01 

82.0 

28.8 

193729 

0.79 

10762.7 

tail 

320 

2663 

0.01 

88.5 

30.1 

235677 

0.89 

13093.2 

resolve.ambiguity 

685 

6453 

0.01 

190.0 

34.0 

1226008 

2.15 

68111.5 

eeeiplete_alt 

325 

1758 

0.03 

61.5 

28.6 

108123 

0.59 

6006.8 

complete.concat 

225 

1758 

0.02 

61.5 

28.6 

108123 

0.59 

6006.8 

ccagilate_opt 

60 

354 

0.06 

16.0 

22.2 

5671 

0.12 

315.0 

store_pattam 

123 

846 

0.03 

32.5 

26.0 

27480 

0.28 

1526.7 

lltakaaction 

1234 

13673 

0.00 

323.5 

39.2 

4099425 

4.22 

227745.8 

Figure  32-5.  ACT  Halstead’s  Metrics  Report 
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ProarM:  ll_coiq>il« 


Module:  llfind 

Progr*K  length  (Nl :  74 
Progren  voluM  (V)  :  459 
Progreai  level  (L) :  0.05 
Progreai  difficulty  (D) :  21.5 
Intelligent  content  (I):  21.4 
Programing  effort  (E)  ;  9879 
Error  eatinete  (B) :  0.15 
Programing  tim  (T) :  548.8 

Module:  llprtatring 

Prograa  length  (N) :  37 
Progran  volum  (V)  :  193 
Progran  level  (L) :  0.10 
Program  difficulty  (O) :  10.5 
Intelligent  content  (I) :  18.4 
Programing  effort  (E| :  2024 
Error  eetimte  (B) :  0.06 
Programing  time  (T)  :  112 . 4 

Module:  llprttoken 

Program  length  (N) :  42 
Program  volume  (V) :  226 
Program  level  (L) :  0 . 09 
Program  difficulty  (O) :  11.5 
Intelligent  content  (I):  19.7 
Programing  effort  (E) :  2604 
Error  estimate  (B) :  0.08 
Programming  time  (T) :  144.7 

Module:  llskiptoken 

Program  length  <N) ;  42 
Program  volume  (V) :  226 
Program  level  (L) :  0.08 
Program  difficulty  (D) :  12.0 
Intelligent  content  (1):  18.9 
Programming  effort  (E) :  2718 
Error  estimate  (B) :  0.08 
Programing  tlsw  (T) :  151.0 

Module:  lltakaaction 

Program  length  (N) ;  1234 
Progrm  volumm  (V) :  12672 
Program  level  (L) :  0.00 
Program  difficulty  (O) :  323.5 
Intelligent  content  (I):  39.2 
Programing  effort  (B)  t  4099425 
Error  estimate  (B) ;  4.22 
Programing  time  (T) :  227745.8 


Figure  32-6.  ACT  Verbose  Halstead’s  Metrics  Report 


Prograa:  ll_ca«|>il* 


Hodul*  Nan* 


llCind 

llprtstrlng 

llprttokm 

llskiptokm 

llaklpnod* 

llakipboth 

11 fatal 

gat_eharactar 

ovt.atring 

■aka.tokan 

llnaxttokan 

buildright 

buildsalact 

raadgraa 

arasa 

■acch 

axpand;! 

synchroniza 

taatayneh 

parsa 

llMin 

ll.coapila 

gat_char 

char.advanca 

look_ahaad 

naxt.eharactar 

naxt.idantifiar 

naxc_spac_sy» 

naxt_8tring 

advaRca 

iiarga_ranga8 

altarnata 

char_ranga 

raatricc 

tail 

rasolva.aaibiguity 

cooplata.alt 

conplata.concat 

coaplata_opt 

coaplata_pat 

eanplata_pattarns 

concatanata 

cvt_ascii 

stora_pattarn 

lltakaaction 


Figure  32-7. 
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Cycloi&aCic  Tast  Paths  Listing 


Program:  ll.compila 

Date/Time: 12/28/92  14:27:43 


Modula  Nana:  llfind  Conplaxity:  5 


Teat 

Path  1: 
148( 

0  1  2  3  15  16  17 

3):  low  /=  high  ==>  FALSE 

Tast 

Path  2: 
148  ( 
150  ( 
148  ( 

0  1  2  3  4  5  6  7  14  3  IS  16  1'- 
3)  :  low  /■  high  •»>  TWJE 

6):  item  <  llaymboltahle (midpoint! .key 
3) :  low  /s  high  ss>  FALSE 

=x>  TRUE 

Tast 

Path  3: 
148  ( 
150  ( 

152  ( 

153  ( 

012345689  10  17 

3):  low  /■  high  •*>  TRO£ 

61:  item  <  llayabolt^dlle (midpoint)  .key  FALSE 

8) :  item  «  llsyBd3oltable(midpoint)  .key  s«>  TRUE 

9) :  llsymboltable (midpoint) .kind  z  which  ax>  TRUE 

Tast 

Path  4: 
148  ( 
150  ( 
152  ( 
148  ( 

0  1  2  3  4  5  6  8  13  14  3  15  16  17 

3):  low  /x  high  3x>  nUE 

6);  item  <  1 Isymbcltabla (midpoint ) .kay 
8):  item  •  llsymboltable (midpoint) .key 
3):  low  !=.  high  ==>  FALSE 

==>  FALSE 

XXV  FALSE 

Tast 

Path  5: 
148  ( 
150  ( 

152  ( 

153  ( 

012345689  11  17 

3)  :  low  /=  high  »>  TRUE 

6):  item  <  llaymboltable(midpoint)  .key  FALSE 

8) :  item  X  llsymboltable (midpoint) .key  ss>  TRUE 

9) :  llsymboltable(mi<)b?oint)  .kind  *  which  xb>  FALSE 

Module  Name: 

llpttstring 

Complexity:  .> 

Test 

Path  1: 
170  ( 

0  1  2  8  9  10 

2):  1  in  str' range  xx>  FALSE 

Test 

Path  2: 

170  ( 

171  ( 

01234589  10 

2)  :  i  in  str 'range  TRUE 

4) :  atr(l)  x  ■  '  xx>  TRUE 

Test 

Path  3: 

170  ( 

171  ( 
170  ( 

0123467289  10 

2):  i  in  str 'range  ax>  TRUE 

4) :  str(i>  X  '  '  x=>  FALSE 

2) :  i  in  str'range  xx>  FALSE 

Module  Name: 

llprt token 

Coofilaxity:  2 

Test 

Path  1: 
181  ( 

0  12  5  6 

1):  llcurtok.printvalue(l)  in  ’ ! '  ..  '' 

■  ’  ==>  TRUE 

Test 

Path  2: 

0  1  3  4  5  6 

Figure  32-8.  ACT  Cyclomatic  Test  Paths  Listing 
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181  ( 


1) :  llcurtok.printv«lu«(l)  in  ' ; ' 


■'  ««>  FALSE 


Modul*  Neune:  llakiptokan  Complexity;  1 


Teat 

Path  1: 

0  1  : 

2  3  4  5  6  7  8 

Test 

Path  56: 

0  1 

136  137  165  166 

28  ( 

1)  : 

caseindex  55 

Test 

Path  57: 

0  1 

138  139  165  166 

28  ( 

1)  : 

caseindex  ea>  S6 

Test 

Path  58: 

0  1 

140  141  142  165  166 

28  ( 

1)  : 

caseindex  e»  57 

Tost 

Path  59: 

0  1 

143  144  165  166 

28  ( 

1)  : 

caseindex  ee>  58 

Test 

Path  60: 

0  1 

145  146  147  165  166 

28( 

1)  : 

caseindex  ■■>  59 

Test 

Path  61: 

0  1 

148  149  165  166 

28  ( 

1)  : 

caseindex  »>  60 

Test 

Path  62: 

0  1 

ISO  151  152  165  166 

28  ( 

1)  : 

caseindex  **>  61 

Test 

Path  63: 

0  1 

153  154  165  166 

28  ( 

1)  : 

caseindex  ss>  62 

Test 

Path  64: 

0  1 

155  156  165  166 

28  ( 

1)  : 

caseindex  ae>  63 

Test 

Path  65: 

0  1 

157  158  165  166 

28  ( 

1)  ; 

caseindex  ee>  64 

Test 

Path  66: 

0  1 

159  160  165  166 

28  ( 

1)  : 

caseindex  »>  65 

Test 

Path  67: 

0  1 

161  162  165  166 

28( 

H  : 

caseindex  **■>  66 

Test 

Path  68: 

0  1 

163  16'4  165  166 

28( 

1)  : 

caseindex  ee>  others 

Figure  32-8.  continued.  ACT  Cyclomatic  Test  Paths  Listing 
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Tasted  Cyclomtic  Tast  Paths  Listing 


Progran:  ll.coapila 

Date/Tine: 12/28/92  13:36:11 

Module  Nasia:  llfind  Coaiplaxity:  5 

Test  Path  1:  01234568  13  14  34S68  13  14  34567  14  34568  13  14 
3  4  5  6  8  9  10  17 

148  (  3 )  :  low  />  high  TRUE 

150  (  6):  itan  <  llsyaboltable (midpoint)  .hay  >»  FALSE 

152 (  8):  itan  s  llsynboltabla(midpoint) .hay  ==>  FALSE 

148 (  3);  low  /s  high  »>  TRUE 

150  (  6):  itan  <  lisynboltabla (midpoint )  .)cay  sx>  FA1.SE 

152  (  8):  item  >  llaymbolt^tbla (midpoint )  .)cay  zac>  FALSE 

148 (  3):  low  /x  high  -»  TRUE 

150(  6):  itan  <  llsynboltabla(nidpoint)  .)cay  TRUE 

148 (  3):  low  /m  high  »>  TRUE 

150(  6):  itan  <  1  Isynboltabla (midpoint )  .)cay  »■>  FALSE 

1S2(  8):  itan  >  llsynboltabla (midpoint )  .)cay  mm>  FALSE 

148 (  3):  low  /m  high  »>  TRUE 

150(  6):  itan  <  llsynboltabla  (midpoint )  .)cay  **>  FALSE 

152(  8):  itan  •  llsynboltabla  (midpoint )  .)cay  TRUE 

153 (  9);  llsymboltabla(midpoint)  .)cind  k  which  mm>  TRUE 

Tast  Path  2:  01234567  14  345689  10  17 
148 (  3):  low  /=  high  TRUE 

1S0(  6):  item  <  llsynboltabla (midpoint) -key  TRUE 

148 (  3):  low  /m  high  »>  TRUE 

1S0(  6):  item  <  llsynboltabla  (midpoint)  .key  ■b>  PA1.SE 

152 (  8):  item  «  llsynboltabla (midpoint) .key  >s>  TRUE 

153  (  9)  s  llsymboltabla(midpoint)  .kind  ■  which  >»  TRUE 

Tast  Path  3:01234568  13  14  34567  14  34567  14  34567  14  345 
6  8  9  10  17 

148 (  3):  low  /m  high  >=>  TRUE 

150  (  6):  item  <  llsynboltabla  (midpoint )  .kay  »>  FALSE 

152(  8):  item  s  llsynboltabla (nd.dpoint)  .key  kk>  FALSE 

148 (  3):  low  /s  high  »»  TRUE 

150(  6):  item  <  llsynboltabla (midpoint) .key  >«>  TRUE 

148(  3):  low  /*  high  »>  TRUE 

1S0(  6):  item  <  llsysdaoltabla (midpoint)  .kay  TRUE 

148  (  3 ) :  low  /£  high  n>  TRUE 

150 (  6):  item  <  llsynboltabla (midpoint) .key  ss>  TRUE 

148 (  3):  low  /e  high  TRUE 

1S0(  6):  item  <  llsynboltabla  (midpoint) .key  >s>  FALSE 

152 (  8):  item  >  llsynboltabla (midpoint) .key  ks>  TRUE 

153 (  9):  llsynboltabla(nidpoint) .kind  >  which  ks>  TRUE 

Tast  Path  4:0123456714345681314345681314345671434 
5  6  8  13  14  3  15  16  17 

148 (  3):  low  /*  high  a»  TRUE 

150  (  6):  itan  <  llsynl3oltabla(nidpoint)  .key  mm>  TRUE 

148 (  3):  low  /-  high  ==>  TRUE 


Figure  32-10.  ACT  Tested  Cyclomatic  Paths  Using  test  1. lex  and  sample.lex 


150( 

6)  : 

1S2( 

8)  : 

148  ( 

3)  : 

150( 

6)  : 

152  ( 

8)  : 

148  ( 

3)  : 

150  ( 

6)  : 

148  ( 

3)  : 

150  ( 

£)  : 

152  ( 

8)  : 

148  ( 

3)  : 

Past  Path  5 

0  1 

5  6  a  9  11 

n 

148( 

3)  : 

150  ( 

6)  : 

148  ( 

3)  : 

1S0( 

6)  : 

152  ( 

8)  : 

148  ( 

3)  : 

150( 

6): 

148  ( 

3)  : 

1S0( 

«l  : 

152  { 

8)  : 

148  ( 

3)  ! 

150( 

6)  : 

152  ( 

8)  : 

153  ( 

9)  : 

itain  <  llaynboltJLbl* (midpoint)  .lc«y  FALSE 
itam  m  llsymboltabla (midpoint)  .Jcay  •>>  FALSE 
low  /s  hiflh  ==>  TRtJE 

itam  <  1  Isyndioltabla (midpoint )  .Icey  »>  FALSE 
itam  s  1  laymboltabla (midpoint )  .kay  n>  FALSE 
low  />  high  aa>  TR(}E 

itam  <  llayndsoltabla (midpoint )  .)iey  »»  TRUE 
low  /=  high  =a>  TRUE 

itam  <  llsymboltabla  (midpoint )  .)cay  b*>  FALSE 
itam  •  llaymboltabla (midpoint)  .Jcay  ««>  FALSE 
low  /=  high  ==>  FALSE 

234S67  14  3456ei3  14  3456'7  14  34568  13  14  34 
low  /-  high  TRUE 

item  <  1  Isymboltable  (midpoint )  .)tay  ao  TRUE 
low  /=  high  ==>  TRUE 

itam  llaymboltebla(midpoint)  .Jcay  mo  FALSE 
itam  m  1  laymboltabla  (midpoint ).  Jcay  mm>  FALSE 
low  /s  high  TRUE 

it«n  <  lleymJaoltabla (midpoint)  .Jcay  ms>  TRUE 
low  /=  high  »m>  TRUE 

itam  <  llaym)x>ltabla (midpoint)  .Jcay  m.>  FALSE 
itam  s  1  laymboltabla  (midpoint ).  Jcay  xs>  FALSE 
low  /=  high  •*>  TRUE 

itam  <  llaymboltabla  (midpoint)  .Jcay  ms>  FALSE 
itam  E  llaymboltabla  (midpoint)  .Jcay  mm>  TRUE 
1  laymboltabla  (midpoint )  .Jcind  m  which  »«>  FALSE 


Modula  Kaaia:  llprtatring 

No  Path 

Modula  Name:  llprttoJcan 

No  Path 


Test 

Path  31: 

0  1 

159  160  165  166 

28  ( 

1): 

caseindax  mE>  65 

Taat 

Path  32: 

0  1 

13  14  IS  16  17  18  165  166 

28  ( 

1)  : 

caaaindax  mm>  4 

Taat 

Path  33: 

0  1 

S3  84  .85  165  166 

28  ( 

1)  : 

caaaindax  mm>  33 

Taat 

Path  34: 

0  1 

62  63  64  165  166 

28  ( 

1)  : 

cwaaindax  mE>  25 

Teat 

Path  35: 

0  1 

128  129  130  131  165  166 

28  ( 

1)  : 

caaaindax  sm>  52 

Cooplaxity : 

Cee(>laxity: 


3 

2 


Figure  32-10.  continued.  ACT  Tested  Cyclomatic  Paths  using  test  1. lex  and  sample.lex 
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II  I,  mi-'. 


Unt«ae«d  Cycloauitic  Taat  Patha  Liacing 


Program:  ll.coopile 

Data/TiJM:12/28/92  13:36:39 


V 

Modula  Nana:  llfind 

Conplexity;  5 

No  Path 

Hodula  Nana:  llprtatring 

Cooplaxity :  3 

• 

Taat  Path  1:  0  1  2  8  9  10 

170 (  2):  i  in  atr' range  =s>  FALSE 

Teat  Path  2:  01234S8910 

170(  2):  i  in  atr'ranga  »>  TROE 

171(  4):  atr(i)  ■  '  '  ««>  TRUE 

• 

Teat  Path  3:  0123467289  10 

170 (  2):  i  in  atr'ranga  >«>  TROE 

171(  4):  atr(i)  =  '  ‘  »■>  FALSE 

170 (  2):  i  in  atr'ranga  as>  FALSE 

Module  Nana:  llprttoken 

Conplexity :  2 

• 

Teat  Path  1:01256 

181 (  1):  lleurtok.printvalue(l)  in  ' 

! '  ' " '  »*>  TRUE 

Teat  Path  2:  013456 

181(  1):  1  lour tok.print valued)  in  ' 

!'  ■»  FALSE 

Modula  Nana :  lla)ciptolcen 

Conplexity :  1 

• 

Teat  Path  1:  012345678 

Module  Naan:  lls)cipnode 

Conplexity :  1 

Teat  Path  1:  0123456789 

• 

Module  Nana:  llaJcipboth 

Conplexity:  1 

Teat  Path  1:  0123456789  10 

Module  Nana:  llfatal 

CoF  laxity:  1 

• 

Teat  Path  1:  01234567 

Module  Name:  get_eharacter 

Test  Path  1:  0  1  2  9  10 

Conplexity:  3 

Figure  32-11. 
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352  ( 


1)  :  and.of.f  il«  (•tand&rd_input)  x>>  ntllE 


Taat  Path 

252(  1):  •nd_of_fila(st«ndard_input)  ax>  FALSE 

254 (  3):  •nd_of_liiia(standard_input)  >■>  FALSE 

Taat  Path  3;  0134549  10 

252(  1):  and_of_fila(standard_input)  ■>>  FALSE 

254 (  3):  and_of_lina(ataiidard_iDput)  *m>  TRUE 


Modula  Mama:  cvt.strlng 


Coopiaxity:  3 


Taat 

Path  1: 

0  17  8 

9 

276  ( 

1)  ! 

1 

in 

llatringa ' ranga 

mm> 

FALSE 

Taat 

Path  2: 

0  12  3 

4 

6  17  8  9 

276  { 

1):  i 

in 

llatringa 'raaga 

«s> 

TRUE 

277  ( 

3)  : 

i 

<M 

atr'laat  ss>  TRUE 

276  ( 

1):  i 

in 

llatringa ‘ ranga 

ss> 

FALSE 

Taat 

Path  3: 

0  12  3 

5 

6  17  8  9 

276  ( 

1)  : 

i 

in 

llatringa ' ranga 

mjt> 

TRUE 

277  ( 

3); 

i 

<m 

atr'laat  **>  FALSE 

276  ( 

1)  : 

i 

in 

llatringa ‘ ranga 

mm> 

FALSE 

Modula  Mama:  naka.tokan 

Taat  Path  1;  0  1  2  3  24  25  26  27  28  29  38  39  40 


Ccxiplaxlty:  11 


288  ( 

31  ; 

noda  xx>  othara 

306( 

27): 

noda  aa>  char 

Teat 

Path  2: 

0  1  ; 

2  3  4  5  6  26  27  28  29 

288  ( 

3): 

noda  mm>  char 

306( 

27): 

noda  sx>  char 

Taat 

Path  28: 

0  1 

148  149  165  166 

28  ( 

1); 

caaaindax  aa>  60 

Taat 

Path  29: 

0  1 

150  151  152  165  166 

28  ( 

1): 

caaaindax  n>  61 

Taat 

Path  30: 

0  1 

153  154  165  166 

28  ( 

1)  : 

caaaindax  >«>  62 

Taat 

Path  31; 

0  1 

155  156  165  166 

28  ( 

1)  : 

caaaindax  3s>  63 

m 

ft 

Path  32; 

0  1 

161  162  165  166 

28  ( 

1)  : 

caaaindax  as>  66 

Taat 

Path  33: 

0  1 

163  164  165  166 

28  ( 

1)  : 

caaaindax  »>  othara 

Figure  32-11.  continued.  ACT  Untested  Cyclomatic  Paths  Using  test  1. lex  and  sample.lex 
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Figure  32-12.  ACT  Tested  Paths  Graph  Using  testl.lex  and  sample.lex 
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Figure  32-14.  BAT  Battlemap  for  Program  LL_COMPILE 
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Figure  32-15.  BAT  Battlemap  Symbology 
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BAttlamap  Analysis  Tool 
Nuawrical  Csllsd-by  Listing 


ProgrsBi  :  ll.cosv^ils  Mon  Dsc  38  13:34:12  1992 

Hod#  Called  module 

Mod*  Calling  module 


1 

ll_coiif>ile 

2 

expand;! 

3 

get_character 

4 

llskipboeh 

5 

llskiptoken 

6 

maka_token 

7 

llmain 

1 

ll.coapile 

8 

match 

2 

expand;! 

9 

cvt_eering 

6 

aiake.token 

10 

readgram 

7 

llmain 

11 

pars* 

7 

llmain 

12 

open 

10 

readgram 

13 

buildright 

10 

readgram 

14 

buildselect 

10 

readgram 

... 

52  llfind 

6  make.token 
11  parse 

40  next.string 

41  next.character 

42  next.identiCiec 

43  next_spec_sym 


Figure  32-17.  BAT  Numerical  Called-by  Listing 
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tattlMMip  AMlyais  Tool 
MiMrical  CailS'to  Listing 


ProgrsM  :  ll_eoapil«  Mon  Dsc  28  13:34:38  1992 


Mod* 

Calling  nodula 

Mod* 

Callsd  modulo 

1 

ll.eoapilo 

7 

llmain 

2 

oxpsndi-1 

8 

match 

16 

tsstsynch 

19 

11 fatal 

61 

put_lina 

3 

gst_eharsceor 

63 

akip_lina 

64 

gat 

4 

llskipboth 

22 

llnaxttokan 

39 

llprttokan 

SO 

llprtstring 

61 

put.lina 

71 

put 

S 

llskiptoksn 

22 

llnaxttokan 

39 

llprttokan 

61 

put.lina 

71 

put 

6 

Mka.telcsn 

9 

evt .string 

52 

llClnd 

1 

llmsin 

10 

rsadgram 

11 

parse 

8 

match 

9 

cvt_string 

10 

rsadgram 

12 

^en 

13 

buildright 

14 

buildsaloet 

S2 

lirind 

Figure  32-18.  BAT  Numerical  Calls-to  Listing 
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BACtlttoap  Analysis  Tool 
Nunarical  Context  Liating 


Progran  :  ll.coagpila 

Mod* 

Module  NasM 

1 

ll.conpila 

2 

expand  ,*1 

3 

gat.charaetar 

4 

llsklpboth 

5 

llsklptokan 

6 

Mka.tokan 

7 

llnain 

8 

match 

9 

cvt.string 

10 

raadgran 

11 

PAra« 

12 

op«n 

13 

bu* idright 

14 

Luildsalact 

15 

close 

16 

tastsynch 

17 

expand 

18 

19 

llfatal 

20 

synchronita 

21 

lltakaaction 

22 

llnaxttokan 

23 

am.it.tokan 

24 

coBplata.paCtarna 

25 

amit.pkg.dacls 

26 

emit.advanca.hdr 

27 

ani  t.advanca.t Ir 

28 

anit.scanjproc 

29 

cvt.ascii 

30 

llskipnoda 

31 

store.pattarn 

32 

cvt.string;! 

33 

repast 

34 

char.ranga 

35 

Include j^ttern 

36 

advance 

37 

caaplata.pac 

38 

amit_patt*mjBateh 

39 

llprttoken 

40 

naxt.string 

41 

naxt.eharaecar 

42 

naxt.idantiCiar 

43 

n«xt_sp«c_aym 

52 

lltind 

/•val/BCC. . -conpila.a 
/eval/BCC. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc. ■ .conpila.a 
/aval /ncc . . . conpi la . a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc . . .conpila.a 
/aval/ncc. .  .cooipila.a 
Coda  Pound) 

/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
Coda  Pound) 

/aval/ncc. . .conpila.a 
Coda  Pound) 

/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .actions. a 
/aval/ncc. . .conpila.a 
/aval/ncc. . .up.body.a 
/aval/ncc. . .up_body.a 
/aval/ncc . . . up_body . a 
/aval/ncc. . .up_body.a 
/aval/ncc. . .up_body.a 
/aval  /ncc . . .  up_body .  a 
/aval /ncc . . . up_body . a 
/aval/ncc. . .conpila.a 
/aval/ncc . . . up_body . a 
/aval/ncc. . .upjbody.a 
/aval/ncc . . . up_body . a 
/aval fmcc  —  up_body . a 
/aval  /ncc — up_body .  a 
/aval/sicc. .  ..cokans.a 
/ava^/TCC. . .up_body.a 

/aval  /ncc _ up_body .  a 

/aval  /ncc  —  conpila .  a 
/aval/ncc. . . .tokens. a 
/aval/ncc. . ..tokans.a 
/aval/ncc. . ..tokana.a 
/aval /ncc . . . .tokens . a 

/aval/Bwc. .  .conpila.a 


Mon  Dac  28  13:34:58  1992 

Latter  File  Nane  ^ 

sXKKsassftssSBBsaasaiBKMaBKxeaiKsssssssssss 

V 
Q 
H 
F 
D 
J 
U 
P 
I 
N 
T 
(No 
L 
M 
(No 
S 
(No 
O 
G 
k 
A 
K 
AA 
K 
0 
0 
P 

z 

H 
E 
AC 
N 
AP 
C 
AB 
H 
J 
W 
C 
G 
D 
E 
P 


Figure  32-19.  BAT  Numerical  Context  Listing 
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Battlaatap  Analysis  Tool 
NuBsrieal  Indsx  Listing 


Program  :  ll_eonpila 

Hon 

DSC  28 

13:33 

:50  1992 

Mod* 

Moduls  Nans 

v(0) 

sv(G) 

iv(G) 

(row, col 

xxxss 

BSSmSSK 

1 

ll_campils 

1 

1 

1 

1.  54 

2 

sxpand;! 

8 

1 

3 

1,109 

3 

gst_charactar 

3 

1 

3 

1,112 

4 

llskipboth 

1 

1 

1 

1,115 

S 

llskiptokan 

1 

1 

1 

1,120 

6 

maks_tok*n 

11 

1 

7 

1,123 

7 

llmain 

1 

1 

1 

2,  54 

8 

match 

4 

4 

1 

2,107 

9 

cvt_*tring 

3 

1 

1 

2,122 

10 

rsadgram 

6 

1 

5 

3,  6 

11 

paras 

11 

1 

9 

3,  59 

12 

opsn 

0 

0 

0 

4,  1 

13 

buildright 

10 

4 

9 

4,  6 

14 

buildaslsct 

2 

1 

2 

4,  9 

15 

cloas 

0 

0 

0 

4,  10 

16 

tsstsynch 

3 

1 

2 

4,  59 

17 

sxpand 

0 

0 

0 

4,104 

18 

srase 

3 

3 

1 

4,105 

19 

llfatal 

1 

1 

1 

5,  15 

20 

synchronizs 

9 

4 

5 

5,  60 

21 

lltaksaction 

68 

1 

40 

6,  58 

22 

llnsxttoksn 

2 

1 

1 

6,  99 

23 

smit.toksn 

11 

9 

8 

7,  23 

24 

complata_pattam* 

2 

1 

2 

7,  36 

25 

amit_pkg..dscls 

3 

1 

3 

7,  48 

26 

smi t_advance_hdr 

1 

1 

1 

7,  51 

27 

smi t_advancs_t Ir 

1 

1 

1 

7,  53 

28 

smi t_scan_proc 

4 

1 

4 

7,  64 

29 

cvt_ascii 

10 

1 

1 

7,  76 

30 

llskipnods 

1 

1 

1 

7,  79 

31 

stors_pattsrn 

6 

5 

2 

7,  83 

32 

evt_string;l 

4 

4 

2 

7,  85 

33 

rspsat 

3 

1 

1 

7,  87 

34 

char_rangs 

3 

1 

1 

7,  88 

35 

includs_patt*m 

2 

1 

2 

7,  92 

36 

advancs 

8 

4 

8 

7,  99 

37 

caaiplsts_pat 

12 

1 

9 

8,  36 

38 

*aiit_patt*rn_match- 

19 

1 

19 

8,  66 

39 

llprttoksn 

2 

1 

2 

8,  80 

40 

nsxt_*tring 

4 

3 

2 

8,  99 

41 

nsxt.charactsr 

3 

1 

3 

8,101 

42 

nsxt.idsntifisr 

4 

1 

3 

8,102 

43 

naxt_spac_sym 

10 

1 

10 

8,103 

52 

llfind 

5 

4 

1 

9,100 

Figure  32-20.  BAT  Numerical  Index  Listing 
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SUBTftBES  AND  ASSOCIATED 

INTEGRATION  TEST  CONDITIONS  FOR  PROGRAM  ll.conpil* 

ROOT  MODUU  OF  PROGRAM:  ll.eoiipll* 

NO  DESIGN  REDUCTION 

SUBTREE  •!: 

ll.conpil*  >  llnain  >  rMdgrAm  >  top«n]  <  raadgram  >  [0*t]  <  raadgram 
>  (akip.lin*]  <  raadgran  >  (cloaa)  <  raadgran  <  llawin  >  paraa  >  llCind 

<  paraa  >  llfind  <  paraa  >  llnaxttokan  >  advanea  <  llnaxttokan  <  paraa 

<  IlBMiin  <  ll.compila 

END-TO-END  TEST  CONDITION  LIST  FOR  SUBTREE  «1: 
raadgran  466(2):  1  in  1  ..  lltablaaiza  »->  FALSE 
raadgran  482(18):  i  in  1  ..  llprodsiza  FALSE 
raadgran  491(27):  i  in  1  ..  llaynehaiza  FALSE 
llfind  148(3):  low  /s  high  »>  FALSE 
llfind  148(3):  low  /-  high  -»  FALSE 

advanea  200(2):  (currant_char  >  aacii.atx)  or  (currant.char  z  aacii.ht)  or  (currant_c. 
advanea  212(14):  currant.ehar  •  aaeii.aoc  •m>  TRUE 
llnaxttokan  342(2):  llaotoka  «»  FALSE 
paraa  680(13):  lltop  />  0  »>  FALSE 

paraa  713(42):  llcurtok.tablalndax  />  llloeaoa  mm>  FALSE 


SUBTREE  42: 

ll.ooaqpila  >  llnain  >  raadgran  >  [opan]  <  raadgran  >  (gat)  <  raadgran 

>  [aklp_llna|  <  raadgran  >  [gat]  <  raadgran  >  (akip_lina]  <  raadgran 

>  [eloaa]  <  raadgran  <'  llnain  >  paraa  >  llfind  <  paraa  >  llfind  <  paraa 

>  llnaxttokan  >  advanea  <  llnaxttokan  <  paraa  <  llnain  <-  ll.coapila 

END-TO-END  TEST  CONDITION  LIST  FOR  SUBTREE  «2: 
raadgran  466(2):  i  in  1  ..  lltablaaiza  a*>  TRUE 
raadgran  467(4):  j  in  1  ..  llatringlangth  »>  FALSE 
raadgran  472(10):  eh  *  'g'  >«>  TRUE 
raadgran  466(2):  i  in  1  ..  lltablaaiza  >>>  FALSE 
raadgran  482(18):  i  in  1  ..  llprodaiza  zb>  FALSE 
raadgran  491(27):  i  in  1  ..  llaynehaiza  *•»  FALSE 
llfind  148(3):  low  /z  high  »>  FALSE 
llfind  148(3):  low  />  high  «z>  FALSE 

advanea  200(2):  (currant_ehar  *  aaeii.atx)  or  (eurrant_ehar  =  aacii.ht)  or  (currant_c' 
advance  212(14):  currant_char  >  aacii.aot  zz>  TRUE 
llnaxttokan  342(2):  llaotoica  z>>  FALSE 
paraa  680(13):  lltop  />  0  FALSE 

paraa  713(42):  llcurto)c.tablaindax  /z  llloeaoa  zz>  FALSE 


SUBTREE  *3: 

ll.conpila  >  llnain  >  raadgran  >  (opan]  <  raadgran  >  [gat]  <  raadgran 

>  [akip.lina]  <  raadgran  >  [gat]  <  raadgran  >  [gat]  <  raadgran  >  [gat] 

<  raadgran  >  [skip_lina]  <  raadgran  >  buildright  <  raadgran  >  buildaalact 

->  [skip_lina]  <  fauildsalact  <  raadgran  >  [eloaa]  <  raadgran  <  llnain  >  paraa 

>  llfind  <  paraa  >  llfind  <  paraa  >  llnaxttokan  >  advanea  <  llnaxttokan 

<  paraa  <  llnain  <  Il_canpile 


Figure  32-22.  BAT  Cyclomatic  Subtrees 
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END-TO-BO)  TEST  CONDITION  LIST  FOR  SUBTREE  *3: 
readgran  466(2):  1  in  1  ..  lltablaaisa  »>  FALSE 
raadgraK  482(18):  i  in  1  ..  llprodsiza  »>  TRUE 

)3uildright  397(3):  i  in  thisrha  ♦  1  ..  thisrhs  +  productions (whichprod)  .cardrhs  sx: 

)3uildaalact  455(2):  i  in  1  ..  productions  (whichprod)  .cards#  1  >■>  FALSE 

rsadgran  482(18):  i  in  1  ..  llprodsis#  FALSE 

rsadgran  491(27):  i  in  1  ..  llsynchsis#  ■»  FALSE 

ll£ind  148(3):  low  /s  high  x.>  FALSE 

llfind  148(3):  low  /-  high  ms>  FALSE 

advanc#  200(2):  (eurrant_c):ar  s  ascii. atx)  or  (curr#nt_ehar  =  ascii. ht)  or  (current 
advanc#  212(14):  curr#nC_char  •  ascii.aot  TRUE 
lln#xtto)can  342(2):  ll#otolca  a»  FALSE 
parse  680(13):  lltop  /-  0  ==>  FALSE 

parse  713(42):  lleurto)c.t^Lbleindex  /a  llloceos  FALSE 


SUBTREE  *4: 

ll_coac>ile  >  llnain  ^  readgram  >  (open]  <  readgran  >  [get]  <  readgran 


SUBTREE  *315; 

ll.eonpile  >  llnain  >  readgran  >  [open]  <-  readgran  >  [get]  <  readgran 

>  (slcip.linel  <  readgran  >  (close]  <  readgran  ■c  llnain  >  parse  >  llfind 

<  parse  >  llfind  <  parse  >  llnexttojcen  >  advance  <  llnextto)csn  <  parse 

>  testsyneh  >  synchronise  >  (put]  <  synchronise  >  llprttoken  >  llprtstring 

>  (put]  <  llprtstring  >  (put]  <  llprtstring  <  llprtto)cen  <  syneluronise 

>  (put]  <  synchronize  >  (put]  <  synchronise  >  [put.line]  <  synchronize 

<  testsyneh  <  parse  <  llnain  <  ll.ccsipile 

END-TO-END  TEST  CONDITION  LIST  FOR  SUBTREE  8315: 
readgran  466(2):  i  in  1  ..  lltablesise  **>  FALSE 
readgran  482(18):  i  in  1  ..  llprodsize  »»  FALSE 
readgran  491(27):  i  in  1  ..  llsynchsize  n>  FAISE 
llfind  148(3):  low  high  »>  FALSE 
llfind  148(3):  low  /»  high  >»  FALSE 

advance  200(2):  (current_char  s  ascii. etx)  or  (current_char  =  ascii. ht|  or  (current 
advance  212(14):  current.char  *  ascii. eot  sk>  TRUE 
llnaxtto)can  342(2):  lleoto)cs  »»  FALSE 
parse  680(13):  lltop  /s  0  s=>  TRUE 

parse  682(16):  llstaclc(llsentptr)  .data. kind  ■»  group  I  literal 

parse  684(17):  llstack(llsentptr) .data.tableindex  >  llcurtok.tableindex  »>  FALSE 

parse  688(20):  llstack(llsentptr) .data.tableindex  s  locofnull  ==>  FALSE 

parse  690(22):  not  llatack(llsentptr) .lastchild  >=>  TRUE 

parse  691(23):  llstack(llsentptr  1)  .data. kind  s  patch  FALSE 

testsyneh  654(1):  llstack(llsentptr) .data.synehindex  *  0  mm>  FAI3S 

llprctoken  181(1):  llcurtok.printvalue(l)  in  ' ! '  ..  >>>  TRUE 

llprtstring  170(2):  i  in  str 'range  =»  FALSE 

synchronize  610(8):  synchdata(i)  .sent  /*  0  FALSE 

synchronize  643(36):  llcurtok.tableindex  m  llloceos  TRUE 

parse  706(37);  lladvance  >■>  FALSE 

parse  680(13):  lltop  />  0  >■>  FAliSE 

parse  713(42):  llcurtok.tableindex  />  llloceos  ss>  FALSE 


Figure  32-22.  continued.  BAT  Cyclomatic  Subtrees 
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UNTBSTID  SUBTKBS  AND  ASSOCXATCX) 

INTBORATION  TSST  CONDITIONS  TOR  PROGRAM  ll.ccnpil* 

ROOT  MODULE  OF  PROGRAM:  ll.coaplla 
NO  DESIGN  REDUCTION 

UNTESTED  SUBTREE  fl: 

ll.conpil*  >  llMin  >  raadgram  >  topan)  <  raadgran  >  (gac]  <  raadgran 
>  (aklp.lina]  <  raadgram  >  tcloaa]  <  raadgran  <  llnain  >  paraa  >  llCind 

<  paraa  >  llfind  <  paraa  >  llnaxttokan  >  advanca  >  look^ahaad  >  gat.ehar 

<  look_ahaad  <  advaaea  <  llnaxctokan  <  paraa  <  llnain  <  ll_caapila 

END-TO-END  TEST  CONDITION  LIST  TOR  UNTESTED  SUBTREE  •!: 
raadgran  4(6(3):  1  in  1  ..  lltablaalaa  -»  TALSE 
raadgran  482(18):  i  In  1  ..  llprodaiaa  TAX^ 
raadgran  491(27):  i  in  1  ..  llaynchalaa  ««>  TALSE 
llfind  148(3):  low  /«  high  »>  TRUE 

llfind  150(6):  itam  <  llnynboltabla(Bddpoinc)  .)cay  TRUE 
llfind  148(3):  low  /•  high  »>  TRUE 

llfind  150(6):  itan  <  llaynboltabla(Bddpoinc) .kay  >■>  TALSE 
llfind  152(8):  itan  *  llaymboltabla(ni4^int)  .kay  TRUE 
llfind  153(9):  llayaboltabla(a:idpoint)  .kind  *  tdiieh  TRUE 
llfind  148(3):  low  /-  high  —>  TRUE 

llfind  150(6):  itam  <  llaynboltabla(nic^int)  .kay  ••>  TRUE 
llfind  148(3):  low  /-  high  TRUE 

llfind  150(6):  itan  <  llaynl3oltablo(nidpoint)  .kay  >■>  FALSE 
llfind  152(8):  item  s  llayntioltabla(mi4>oint)  .kay  ■■>  TRUE 
llfind  153(9):  llayml3oltabla(aidpoint)  .kind  =  which  TRUE 

advance  200(2):  (currant_char  *  aacii.atx)  or  (currant^char  ■  aacii.ht)  or  (curranc.c: 

advance  204(4):  currant_char  s  »>  TRUE 

gat.char  58(1):  and_of_flla(atandard.input)  »>  TRUE 

advanca  206(6):  look_ehar  /a  »>  TRUE 

advance  313(14):  eurrant.ehar  >  aacii.aot  **■>  TRUE 

llnaxttokan  342(3):  llaotoka  aa>  FALSE 

paraa  680(13):  lltop  /s  0  ss>  FALSE 

paraa  713(42):  llcurtok.tablaindex  />  lllocaoa  FALSE 


UNTESTED  SUBTREE  «2: 

ll.coapila  >  llmain  >  raadgram  >  (open]  <  raadgran  >  [gat]  <  raadgran 
>  (a)iip_lina]  <  raadgran  >  [gat]  <  raadgram  >  (gat)  <  raadgran  >  [akip_llna] 

<  raadgran  >  [cloaa]  <  raadgran  <  llnain  >  paraa  >  llfind  <  paraa  >  llfind 

<  paraa  >  llnaxttokan  >  advance  >  look_alMad  >  gat_cliar  <  look^ahaad 

<  advanca  <  llnaxttokan  <  paraa  <  llnain  <  ll_eoavila 

END-TO-END  TEST  C(E(DITION  LIST  FOR  UNTESTED  SUBTREE  «2: 
raadgran  466(2):  i  in  1  ..  lltablaaiza  FALSE 
raadgran  482(18);  i  in  1  ..  llprodaiza  s3>  FALSE 
raadgran  491(37):  i  in  1  ..  llaynchaiaa  ra>  TRUE 
raadgran  491(27):  i  in  1  ..  llaynchaiaa  mm>  FALSE 
llfind  148(3):  low  />  high  TRUE 

llfind  150(6):  itan  <  1 laynbol table (nidpoint) .key  **>  TRUE 
llfind  148(3):  low  /*  high  -»  TRUE 

llfind  150(6):  itam  <  1  layniiol table (addpoint)  .key  »>  FALSE 
llfind  152(8):  itan  ■  llaynboltabla (midpoint) .key  aa>  TRUE 


Hgure  32-23.  BAT  Untested  Cyclomatic  Subtrees 


llflnd  153(9):  llsymboltabl* (midpoint)  .kind  x  which  »>  TRUE 
llfind  148(3):  low  />  high  »>  TRUE 

llfind  150(6::  it«m  <  llsymboltabl* (midpoint ) .k*y  ax>  TRUE 
llfind  148(3):  low  /-  high  -»  TRUE 

llfind  150(6):  lt«m  <  llsynboltabl«(midpoint)  .k*y  »>  FALSE 
llfind  152(8):  it«m  =  1 Isymboltabl* (midpoint ) .k«y  ==>  TRUE 
llfind  153(9):  llsymboltabl* (midpoint)  .kind  «  which  x»  TRUE 

Advnnc*  200(2):  (curr«nt_ch«r  ■  aaeii.otx)  or  (curr«nt_ch*r  >  aacii.ht)  or  (currant_c 

advanca  204(4):  currant_char  >  »>  TRUE 

gat_char  58(1):  and_of_fila(standar<l_input)  ss>  TRUE 

advanca  206(6):  look^char  /»  ■»>  TRUE 

advanea  212(14):  currant.ehar  ■  aacii.aot  ■«>  TRUE 

llnaxttokan  342(2):  llaoto)ca  »>  PALiSE 

paraa  680(13):  lltop  />  0  FALSE 

paraa  713(42):  llcurtok.tablaindax  /m  lllocaoa  mm>  FALSE 


UNTESTED  SUBTREE  83: 

ll_eoa«>ila  >  llmain  >  raadgram  >  (opanl  <  raadgram  >  [gat]  <  raadgram 

>  [aklp_lina]  <  raadgram  >  (gat]  <  raadgram  >  (gat]  <  raadgram  >  (gat] 

<  raadgram  >  (aklp_lina]  <  raadgram  >  Isuildright  <  raadgram  >  buildsalact 

>  (skip.llna]  <  buildaalact  <  raadgram  >  [closa]  <  raadgram  <  llmain  >  paraa 

>  llfind  <  paraa  >  llfind  <  parse  >  llnaxttokan  >  advance  >  look_abead 

>  get_char  <  look_ahead  <  advance  <  llnaxttokan  <  paraa  <  llmain  <  ll.coaopila 

END-TO-END  TEST  CONDITION  LIST  FOR  UNTESTED  SUBTREE  83: 
raadgram  466(2):  i  in  1  ..  lltablesisa  m*>  FALSE 
raadgram  482(18);  i  in  1  ..  llprodaisa  **>  TRUE 

buildright  397(3):  i  in  thisrhs  «  1  ..  thisrha  *  productions (whichprod)  .eardrha  »>  P. 

buildaalact  455(2):  i  in  1  ..  productions (whichprod) .cardsal  ss>  FALSE 

raadgram  482(18):  i  in  1  ..  llprodaite  sa>  FALSE 

raadgram  491(27):  i  in  1  ..  llsynchsixa  aa>  FALSE 

llfind  148(3):  low  /=  high  »>  TRUE 

llfind  150(6);  item  <  llsyisboltable(Bddpolnt)  .key  TRUE 
llfind  148(3):  low  />  high  ■»  TRUE 

llfind  150(6):  item  <  llsymboltabla (midpoint) .key  3s>  FALSE 
llfind  152(8):  item  >  llsymboltabla (mi^^int)  .key  aa>  TRUE 
llfind  153(9):  llsyBdaoltabla(mldpoint)  .kind  a  which  as>  TRUE 
llfind  148(3):  low  /m  high  sa>  TRUE 

llfind  150(6):  item  <  llsymboltable (midpoint) .key  Ba>  TRUE 
llfind  148(3):  low  /=  high  3=>  TRUE 

llfind  150(6):  item  <  llsymboltabla (midpoint) .key  ■>>  FALSE 
llfind  152(8):  item  ■  llsymboltabla (midpoint) .key  *m>  TRUE 
llfind  153(9):  llsymboltable(midpoint)  .kind  *  which  TRUE 

advanca  200(2):  (eurrant.char  «  ascii. etx)  or  (currant_c)tar  >  ascii. ht)  or  (currant_c: 

advance  204(4);  currant_c)uir  s  x3>  TRUE 

gat_char  58(1):  and_of_fila(standard_ii^t)  >«>  TRUE 

advance  206(6):  look_e)tar  /*  mm>  TRUE 

advance  212(14);  currant.char  s  ascii. eot  **>  TRUE 

llnaxttokan  342(2):  llaoto)(s  ■»  FAliSE 

paraa  680(13):  lltop  /m  0  aa>  FALSE 

parse  713(42):  llcurtok.tablaindax  />  lllocaos  mm>  FALSE 
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SUBTMtlS  AM)  ASSOCIATCD 

nmORATION  TIST  CONDITIONS  FOR  PROGRAM  ll_ea«|>il« 
ROOT  MODULE  OP  PROGRAM:  ll.coiVil* 


SUBTREE  *1: 

>  llMin  >  rMulorMi  >  [op*n]  <  r—dgrtut  >  [««cl  <  rMdftraa 
>  (•kip_lin«l  <  rMdgrwB  >  [elec*)  <  r«*dgr«a  <  llMln  >  p*rmm  >  llfind 

<  pars*  >  llClnd  <  para*  >  lln*xttek«n  >  advanc*  <  llnaxttolcan  <  pars* 

<  llaMin  <  ll_caa«>ll* 

END-TO-END  TEST  CONDITION  LIST  FOR  SUBTREE  fl: 
r**doraM  4SC(2)i  i  in  1  ..  llt*bl**is*  -»  FALSE 
raadgrMi  4a2(lS):  i  in  1  . .  llprodsls*  «»  FALSE 
raadgraa  491(27):  i  in  1  ..  llaynchais*  sx>  FALSE 
llfind  148(3):  low  />  high  -»  FALSE 
llfind  148(3):  lew  /•  high  >«>  FALSE 

advanc*  200(2):  (eurrant.char  =  ascii. *tx)  or  (currant.ehar  «  ascii. ht)  or  (currant _c 
advanc*  212(14):  curr*nc_char  -  ascii. *ot  m>  TRUE 
llnaxttolcan  342(2):  llaotoica  mm>  FALSE 
para*  480(13);  lltop  /*  0  kx>  FALSE 

pars*  713(42):  llcurto)c.tabl*lnd*x  /*  lllocaoa  >»  FALSE 


SUBTREE  42: 

ll_caag>ll*  >  llaain  >  raadgraa  >  (op*n)  <  raadgraa  >  [g*t)  <  raadgraat 

>  (*)cip_lln*]  <  raadgraa:  >  (gat)  '<  raadgraa:  >  (slcip.linal  <  raadgraa 

>  (elesa]  <  raadgraa:  <  llaain  >  pars*  >  llfind  <  pars*  >  llfind  <  pars* 

>  llnaxttolcan  >  advanc*  <  llnaxttolcan  <  pars*  <  llascin  <  ll_coapil* 

END-TO-END  TEST  CONDITION  LIST  FOR  SUBTREE  #2 : 
raadgraa:  446(2):  i  in  1  ..  lltablasiz*  >»  TRUE 
raadgraa  447(4);  j  in  1  ..  llstringlangth  FALSE 
raadgraa  472(10):  eh  «  'g'  ■*>  TRUE 
raadgraa  444(2):  i  in  1  ..  iltablasis*  «»  FALSE 
raadgraa  482(18):  1  in  1  ..  llprodsiz*  aa>  FALSE 
raadgraa  491(27):  i  in  1  ..  llsynchsiaa  sx>  FALSE 
llfind  148(3):  low  />  high  >->  FALSE 
llfind  148(3):  low  />  high  ■»  FALSE 

advance  200(2):  (currant.ebar  ■  ascii. atxl  or  (curr*nt_char  ■  ascii. ht)  or  (eurr*nt_c' 
advance  212(14):  eurrant.char  ■  ascii. aot  mm>  TRUE 
llnaxttolcan  342(2):  llaotohs  FALSE 
pars*  680(13):  lltop  />  0  *»  FALSE 

pars*  713(42):  llcurtok^tablaindax  />  lllocaos  =s>  FALSE 


SUBTREE  43: 

ll_coa:pil*  >  llsain  >  raadgraa  >  (open)  <  raadgraa  >  [gat]  <  raadgraa 

>  [ship.lina]  <  raadgraa  >  [gat]  <  raadgraa  >  [gat]  <  raadgraa  >  [gat] 

<  raadcpraa  >  [skip.lina]  <  raadgraa  >  buildright  <  raadgraa  >  buildsalaet 

>  [skip.lina]  <  buildsalaet  <  raadgraa  >  (eloaa)  <  raadgraa  <  llaaia  >  pars* 

>  llfind  <  pars*  >  llfind  <  pars*  >  llnaxttokaa  >  advance  <  llnaxttokan 

<  pars*  <  llaain  <  ll^coapil* 
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mO-TO-gHD  TEST  CONDITION  LIST  FOR  SUBTREE  *3: 
r««dgrM  466(3):  i  in  1  ..  lltnblasis*  FALSE 
rMdaraa  482(18):  i  in  1  ..  llprodalx*  ««>  TRUE 

buildright  397(3):  i  in  thiarhs  *  1  ..  chisrhs  «  productions (tdtichprod) .cnrdrhs  ■«>  F 

buildsalact  455(2):  i  in  1  ..  productions (trttichprod) . cardaal  ■«>  FALSE 

rsadgraa:  483(18):  i  in  1  ..  llprodsis*  »■>  FALSE 

rasdgrsB  491(37):  i  in  1  ..  llsynchaiss  ■«>  FALSE 

llfind  148(3);  low  /-  high  —>  FALSE 

llfind  148(3):  low  />  high  »>  FALSE 

sdvanca  300(2):  (currsnt_ehar  >  sacii.stx)  or  (eurrsnt.ehsr  ■  ascii. ht)  or  (eurront_c 
sdvnnes  312(14):  eurrant_ehsr  •  sseii.sot  bk>  TRUE 
llnsxcto)csn  342(3):  llsotoJcs  FALSE 
paras  680(13):  lltop  /s  0  «»  FALSE 

parsa  713(43):  lleurtok.tablsindax  /■  llloeaos  >«>  FALSE 


SUBTREE  M: 

ll_coa4?ila  >  llsMin  >  raadgran  >  [open]  <  rsadgram  >  (gat)  <  raadgran 


SUBTREE  •197; 

ll.coapila  >  lljtain  >  >  [opan]  <  raadgran  >  [gat]  <  raadgran 

>  (slcip.linal  <  raadgran  >  (closa]  <  raadgran  <  ILsain  >  parsa  v  llfind 

<  parsa  >  llfind  <  parsa  >  llnaxttokan  >  advanca  <  llnaxttokan  <  parsa 

>  taatsynch  >  tynchronisa  >  [put]  <  synchroniza  >  llprttokan  >  llprtscring 

>  (iput]  <  llprtstring  >  [put]  <  llprtstring  <  llprttoJtan  <  Rynehronisa 

>  [put]  <  synchroniza  >  (put]  <  synchroniza  >  [put.lina]  <  synchroniza 

<  tastsyneh  <  parsa  <  llnaln  <  ll_coa4>ile 

END-TO-END  TEST  CONDITION  LIST  FOR  SaBTKBE  *197: 
raadgran  466(2):  i  in  1  ..  lltablaaiza  ss>  FALSE 
raadgran  482(18):  i  in  1  ..  liprodaiza  FALSE 
raadgran  491(27):  1  in  1  ..  llsynchsiza  xs>  FALSE 
llfind  148(3):  low  />  high  -»  FALSE 
llfind  148(3):  low  />  high  ■»  FALSE 

advanca  300(2):  (currant_ehar  «  ascii. atx)  or  (ourrant.char  •  ascii. ht)  or  (currant.c 
advanca  212(14):  currant.ehar  m  ascii .aot  xa>  TRUE 
llnaxttokan  342(2):  llaotoks  sx>  FALSE 
parsa  680(13):  lltop  /m  0  ■■>  TRUE 

parsa  682(16):  llstack(llsantptr) .data. kind  ■«>  group  I  litaral 

parsa  684(17);  llstack(llsantptr) .data.tablaindax  >  llcurtok.tablaindax  »>  FALSE 

parsa  688(30):  llstack(llsantptr) .data.tablaindax  >  locofnull  >=>  FALSE 

parsa  690(22):  not  llstaek(llsontptr)  .lastchild  n>  TRUE 

parsa  691(23):  llstackdlsantptr  4-  1)  .data. kind  «  patch  FALSE 

tastsyneh  654(1):  llstackdlsantptr )  .data. synchindax  x  0  xk>  FALSE 

llprttokan  181(1):  lleurtok.printvaluad)  in  '!'  ..  xx>  TRUE 

llprtstring  170(2):  i  in  str'ranga  x»  FALSE 

synchroniza  610(8):  synehdata(i) .sant  /x  0  xk>  FALSE 

synchroniza  643(36):  llcurtok.tablaindax  x  llloeaos  x»  IRUE 

parsa  706(37):  lladvanea  xx>  FALSE 

parsa  680(13):  lltop  /■  0  ax>  FALSE 

parsa  713(42):  llcurtok.tablaindax  /m  llloeaos  xm>  FALSE 
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ONTISTBD  SOBTRIRS  AND  ASSOCZATID 

HREORATZON  test  conditions  for  program 
ROOT  noddle  of  VtLOCaJM:  ll.ctMpil* 


UNTESTED  SUBTREE  *1: 

ll.eaMpil*  >  XlMin  >  rMdgr«B  >  (op«n]  <  rMdgram  >  [g«t)  <  rMdgraa 
>  [aRlp.Iin*]  <  raadgm  >  [eleaa]  <  rMkdgram  <  llMln  >  para*  >  llfind 

<  para*  >  llfind  <  para*  >  lln*xttok*n  >  advanc*  >  look_ah*ad  >  g*t_ehar 

<  leek_ah*ad  <  advanc*  <  lln*xctok*n  <  para*  <  llButin  <  ll.coaipll* 

END-TO-END  TEST  CONDITION  UST  FOR  ONTBSTED  SUBTREE  *1; 
raadgram  466(2):  i  la  1  ..  llcabl*ala*  FALSE 
rnadgraai  482(18):  1  In  1  ..  llprodala*  FALSE 
raadgran  491(27):  1  In  1  . .  llaynOwla*  m»  FALSE 
llfind  148(3):  low  /a  )ilgh  »>  TRUE 

llfind  150(6):  lt*B  <  llayBl9oltabl*(«l^olnt)  .)c*y  «»  FALSE 
llfind  152(8):  it*M  ■  ll*yaboltabl*(ad.dpolnc)  .)c*y  >■>  FALSE 
llfind  148(3):  low  /m  high  ss>  TRUE 

llfind  150(6):  itaai  <  1  layaboltabla (midpoint )  .lc*y  ■«>  FALSE 
llfind  152(8):  Item  -  ll*ymbolt*bl*(nl4x>lat)  .)c*y  >»  FALSE 
llfind  148(3);  low  /m  high  TRUE 

llfind  150(6):  Itaa  <  llaymlaoltabl* (midpoint )  .)c*y  »>  TRUE 

llfind  148(3):  low  /«  high  >■>  TRUE 

llfind  150(6):  itan  <  llaymboltabl* (midpoint)  .]c*y  FALSE 

llfind  152(8):  itam  >  llaymbolt*bl*(ml4l>olnt)  .)c*y  **>  FALSE 

llfind  148(3):  low  /-  high  -»  TRUE 

llfind  150(6):  Itam  <  llaymboltabl* (midpoint )  .)c*y  FALSE 

llfind  152(8):  Itam  >  llaymboltabl* (mld^lnt)  .)c*y  »>  TRUE 

llfind  153(9);  1  laymboltabl* (midpoint )  .Iclnd  *  which  *»  TRUE 
llfind  148(3):  low  /■  high  -»  TRUE 

llfind  150(6):  Item  <  llaymboltabl«(ml^olnt)  .)c*y  ■■>  FALSE 
llfind  152(8);  Itam  *  llaymboltabl* (midpoint )  .)c*y  ««>  FALSE 
llfind  148(3) :  low  /«  high  *«>  TRUE 

llfind  150(6);  Itam  <  llaymboltabl* (ad4^1nt )  .)c*y  ■»  FALSE 

llfind  152(8):  item  a  llaymlsoltabl* (midpoint )  .)c*y  FALSE 

llfind  148(3):  low  /a  high  aa>  TRUE 

llfind  150(6):  itam  <  1  laymboltabl* (mlcb^olnt )  .)c*y  ax>  TRUE 
llfind  148(3):  low  /a  high  aa>  TRUE 

llfind  150(6):  lt*m  <  1  laymboltabl* (midpoint )  .)c*y  **>  FALSE 
llfind  152(8):  Itam  a  llaymboltabl* (mld^int )  .)c*y  aa>  FALSE 
llfind  148(3):  low  /a  high  aa>  TRUE 

llfind  150(6):  Itam  <  llaymboltabl* (midpoint )  .]c*y  **>  FALSE 
llfind  152(8):  Itam  a  llaymboltabl* (midpoint )  .)i*y  aa>  TRUE 
llfind  153(9):  1  laymlMltabl* (midpoint )  .)clttd  a  which  aa>  TRUE 

advanc*  200(2):  (currcnt.char  a  aacll.atx)  or  (curr*nt_c)var  a  aacll.ht)  or  (curr*nt_c' 

advanc*  204(4):  curr*nt_char  a  aa>  TRUE 

g*t_char  58(1):  «nd_of_fil*(atandard_lnput)  aa>  TRUE 

advanc*  206(6):  loo)c_ehar  /a  aa>  TRUE 

advanc*  212(14):  curr*nt_cbar  a  aacil.oot  aa>  TRUE 

lln*xtto)c*n  342(2);  ll*oto)ca  xa>  FALSE 

para*  680(13):  lltop  /a  0  aa>  FALSE 

para*  713(42):  llcurto)c.tabl*lnd*x  /a  llloc*oa  aa>  FALSE 


Figure  32-25.  BAT  Untested  Design  Subtrees 
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UNTESTED  SUBTREE  *2: 

ll.conpila  >  IXmain  >  taadgraa  >  (op«nl  <  raadgran  >  (9«t)  <  raadgran 
>  (■kip.llna]  <  raadgran  >  (gat]  <  raadgraa  >  {gat]  <  raadgran  >  [skip.Iina] 

<  raadgran  >  [eloaa]  <  raadgran  <  llnain  >  paraa  >  lllind  <  parsa  >  Xlfind 

<  parsa  >  llnaxttokan  >  advanca  >  look_abaad  >  gac.char  <  look_ahaad 

<  advanca  <  llnaxttokan  <  paraa  <  llnain  <  ll.eonpila 

END-TO-END  TEST  CONDITION  LIST  FOR  UNTESTED  SUBTREE  *2: 
raadgran  466(2):  i  In  1  . .  lltablaaisa  «»  FALSE 
raadgran  482(18):  i  in  1  ..  llprodaisa  **>  fMJSS 
raadgran  491(27):  i  in  1  ..  llaynchaixa  »>  TRUE 
raadgran  491(27):  1  in  1  ..  llaynchaiza  «»  FALSE 
llfind  148(3):  low  /*  high  az>  TRUE 

llfind  150(6):  Itan  <  llsynboltabla(nid^inc)  .kay  ==>  FALSE 
llfind  152(8):  itan  ■  llaynboltabla(nidpoint)  .kay  »>  FALSE 
llfind  148(3):  low  /-  high  >»  TRUE 

llfind  150(6):  itan  <  llayn)»oltabla(nldpoint)  .kay  zb>  FALSE 
llfind  152(8):  itan  >  llaynboltabla(nidpoinc)  .kay  »->  FALSE 
llfind  148(3):  low  /-  high  «»  TRUE 

llfind  150(6):  itan  <  llsynboltabla (midpoint) .kay  •«>  TRUE 
llfind  148(3):  low  /-  high  >»  TRUE 

llfind  150(6):  itan  <  llaynboltabla(nl^l>oint)  .kay  ■«>  FALSE 
llfind  152(8):  itan  ■  llaynboltabla(ni4^inc)  .kay  n>  FALSE 
llfind  148(3):  low  /■  high  »>  TRUE 

llfind  150(6):  itan  <  llaynboltabla(mic^iBt)  .kay  a8>  FALSE 

llfind  152(8):  itan  ■  llaynboltabla (midpoint)  .kay  »>  TRUE 

llfind  153(9);  llsynboltabla (midpoint) .kind  *  which  aav  TRUE 
llfind  148(3):  low  /m  high  am>  TRUE 

llfind  150(6):  itan  <  llsynbeltabla(ni^point)  .)iay  FALSE 

llfind  152(8):  itan  s  llsyn)aoltabla(ni^^int)  .kay  **>  FALSE 

llfind  148(3):  low  /a  high  »>  TRUE 

llfind  150(6):  itan  <  llsynboltabla (nidpoint) .kay  •m>  FAldX 
llfind  152(8):  itan  ■  llsyniMltabla (nidpoint)  .kay  »>  FALSE 
llfind  148(3):  low  /•  high  »>  TRUE 

llfind  150(6):  itan  <  llsynboltabla(nidpoint)  .kay  n>  TRUE 
llfind  148(3):  low  /«  high  TRUE 

llfind  150(6):  itan  <  llsynlaoltabla(ni4^int)  .kay  so  FALSE 
llfind  152(8):  itan  s  llnynl»oltabla (nidpoint)  .kay  ss>  FALSE 
llfind  148(3):  low  /s  high  ss>  TRUE 

llfind  150(6):  itan  <  llsynboltabla (nidpoint) .kay  ss>  FALSE 
llfind  152(8):  itan  s  llsynboltabla (nidpoint) .kay  8s>  TRUE 
llfind  153(9):  llsyn)aoltabla(nidpoint)  .kind  s  which  ssk  TRUE 

advance  200(2);  (currant.char  s  ascii. atx)  or  (currant.cbar  s  ascii. ht)  or  (currant_c 

advanca  204(4):  currant_c)tar  s  ss>  TRUE 

gat_char  58(1):  and_of_fila(standard_input)  ■>>  TRUE 

advanca  206(6):  loo)(_char  /s  ss>  TRUE 

advanca  212(14):  currant_char  s  ascii. aet  ss>  TRUE 

llnaxttokan  342(2):  llaoto)cs  ss>  FALSE 

paraa  680(13):  lltop  /s  0  sa>  FALSE 

parsa  713(42):  lleurtok.tablaindax  /s  lllocaes  ss>  FALSE 


Figure  32-25.  continued.  BAT  Untested  Design  Subtrees 


BRANCH  METRICS  FOR  PROGRAM  ll.coopila 


MODULE 

•BRANCHES 

llMin 

1 

•ni  t_«dv«nc* 

1 

llfAtAl 

1 

llakipeokm 

1 

llakipnod* 

1 

llaklpboth 

1 

l.ook_«haad 

1 

ami c_advAnea_t Ir 

1 

ll.compila 

1 

look_ahaad;l 

1 

llprteokan 

3 

llaaxtcokan 

3 

buildaalaet 

3 

canplata_pattarna 

3 

includa_pattarn 

3 

&wrg«_ran9«s 

3 

eomplata_opt 

4 

option 

4 

rapaat 

4 

taacayneh 

S 

look_up_pattarn 

5 

llfind 

9 

raadgram 

11 

atora_paCtarn 

11 

amic.char 

12 

coBplata_conc«t 

13 

conplata.alt 

15 

advanca 

15 

maka.tokan 

15 

buildright 

15 

axpand;! 

15 

amic.aalaec 

17 

coa|>lata_pat 

17 

tail 

17 

aynehronica 

17 

naxc_apac_aym 

19 

amit.tokan 

19 

parse 

19 

evt_aacii 

19 

raatricc 

24 

altarnata 

27 

raaolva.ambiguity 

29 

aaic_pattarii_mateh 

32 

Iltakaaetion 

69 

Figure  32-26.  BAT  Branch  Count  Metrics 
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MorULE  CYCLOMATIC  COMPLEXITY  v(G)  FOR  PROGRAM  ll.conpile 
MOD  •  MODULE  ACTUAL  COMPLEXITY  vs  v(G) 


llfind 

50  llprtscring 

39  nprttokan 

5  llskiptoiMn 
30  llsklpnod* 

4  llskipboth 

19  llfatal 

3  gat_charactar 
9  cvt_atring 

6  Mka.cokan 
22  llnaxttokan 

13  buildright 

14  buildsalact 

10  readgram 
18  araaa 

8  sntch 
2  expand; 1 

20  synchronize 

15  testsynch 

11  parse 

7  llmaln 

1  ll.CQsnpile 
57  get.char 

51  char.advance 
S3  look_ahead 

41  next .character 

42  next.identiCier 

43  next.spec.sym 

40  nexc.string 
36  advance 

72  merge.ranges 
70  alternate 
34  char.range 


49  «Bit_concat_right 
38  eau.t.pattom_vatch 
68  enit.char 
62  eait.select 
28  emit.scanjproc 
23  emit.token 
35  include.^attern 
60  look.ahead;l 
46  looK_up.pattem 
66  option 
33  repeat 
31  store j^t  tern 
21  lltakeaction 


3 

12 

2 

5 

2 

5 

1 

0 

2 

1 

1 

2 

35 


3 
19 
11 
10 

4 

11 

2 

1 

3 

3 

3 

6 

68 


Figure  32-29.  Instrumentation  Tool  Module  Complexity  for  testl.lex  and  sample.lex 
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BRANCH  METRICS  FOR  PROGRAM  ll.compile 


MODULE 

•BRANCHES 

•COVERED 

•COVERED 

llnain 

1 

1 

100 

•■iit_advanc»_)idr 

1 

1 

100 

llfatal 

1 

0 

0 

llsklptokan 

1 

0 

0 

llakipnoda 

1 

0 

0 

Ilskipboth 

1 

0 

0 

look_ahaad 

1 

1 

100 

amit_advanca_t Ir 

1 

1 

100 

ll_campila 

1 

1 

100 

look_ahaad; 1 

1 

0 

0 

llprt token 

3 

0 

0 

llnexttoken 

3 

3 

100 

buildselact 

3 

3 

100 

conplete_pattems 

3 

3 

100 

include_pattern 

3 

2 

66 

merge.rangea 

3 

3 

100 

conplete.opc 

4 

2 

50 

option 

4 

2 

50 

repeat 

4 

2 

50 

testsynch 

5 

0 

0 

look_up_pattern 

5 

4 

SO 

eraae 

5 

5 

100 

get.char 

5 

5 

100 

char_advanee 

5 

5 

100 

cvt_string 

5 

0 

0 

next.character 

5 

2 

40 

aBiit_concat_tight 

5 

5 

100 

eaii  t_pkg_dec  1  a 

5 

4 

80 

llprtatring 

5 

0 

0 

char_range 

5 

5 

100 

einit_pattem_naaw 

5 

0 

0 

gat_character 

5 

0 

0 

eni t_scan_proc 

7 

6 

85 

enit_alt_caaea 

7 

7 

100 

einit_pattem_naiee ;  1 

7 

6 

85 

next_identif ier 

7 

6 

85 

naxt_etring 

7 

5 

71 

cvt_atring;l 

7 

5 

71 

natch 

7 

5 

71 

concatenate 

7 

5 

71 

emit_concat_caaea 

8 

7 

87 

llfind 

9 

9 

100 

readgram 

11 

11 

100 

atore_pattern 

11 

6 

54 

emit_pattem_x>atch 

32 

23 

71 

lltakeaction 

69 

36 

52 

Figure  32-30.  Instrumentation  Tool  Branch  Coverage  tor  test  1. lex  and  sample.lex 
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Testing  Sumuiry 


Progreun  :  ll_campile 

Root  eiQMUid ;  1 

82 

Root  0et_charactar 

0 

Root  ll.conpile 

89 

Root  llskipboth 

19 

Root  llskiptoken 

19 

Root  aiake_token 

1 

Mon  Dae  26  13: 


out 

of 

178 

design 

subtrees 

tested 

out 

of 

3 

design 

subtrees 

tested 

out 

of 

197 

design 

subtrees 

tested 

out 

of 

28 

design 

subtrees 

tested 

out 

of 

28 

des ign 

subtrees 

tested 

out 

of 

7 

design 

subtrees 

tested 

.-30  1992 


The  following  modules  have  not  been  executed: 


llprtstring  (  3 
llprttoken  (  2 
llskiptoken  (  1 
llskipnode  (  1 
llskipboch  (  1 
llfatal  (  1 
get_charactar  (  3 
cvt_string  (  3 
raake_token  (  11 
synchronize  (  9 
testsynch  (  3 
amit_pattern_nane  (  3 
look_ahead ; 1  (1 


paths 

paths 

path 

path 

path 

path 

paths 

paths 

paths 

paths 

paths 

paths 

path 


untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 

untested 


)  . 
)  . 
)  . 
)  . 
)  . 
)  . 
)  . 
)  . 
)  - 
)  . 
)  - 
)  - 
)  . 


The  following  nodules  have  been  partially 

tested: 

buildright 

( 

7  of 

10 

paths 

tested 

)  . 

buildselect 

( 

1  of 

2 

paths 

tested 

)  . 

readgram 

( 

1  of 

6 

paths 

tested 

)  . 

match 

( 

2  of 

4 

paths 

tested 

)  . 

expand;! 

( 

6  of 

8 

paths 

tested 

)  . 

parse 

( 

2  of 

11 

paths 

tested 

)  . 

next_character 

( 

1  of 

3 

paths 

tested 

)  . 

next.identifier 

» 

3  of 

4 

paths 

tested 

)  . 

noxt_spec_syin 

( 

7  of 

10 

paths 

tested 

)  . 

nsxt_string 

( 

1  of 

4 

paths 

tested 

)  . 

advance 

( 

7  of 

8 

paths 

tested 

)  - 

aierge_ranges 

( 

1  of 

2 

paths 

tested 

) . 

alternate 

( 

6  of 

14 

paths 

tested 

)  . 

ehar_range 

< 

2  of 

3 

paths 

tested 

)  . 

restrict 

( 

7  of 

14 

paths 

tested 

)  . 

tail 

( 

2  of 

11 

paths 

tested 

)  . 

resolve.ombiguity 

( 

1  of 

15 

paths 

tasted 

)  . 

conplete.alt 

( 

3  of 

8 

paths 

tested 

)  . 

conplete_concat 

( 

4  of 

8 

paths 

tasted 

)  . 

co«plete_opt 

( 

1  of 

3 

paths 

tested 

)  . 

complete_pat 

( 

6  of 

12 

paths 

tested 

). 

cog^lete_patterns 

( 

1  of 

2 

paths 

tested 

)  . 

concatenate 

( 

2  of 

4 

paths 

tested 

)  . 

cvt_ascil 

( 

1  of 

10 

paths 

tested 

)  . 

cvt_3tring;l 

( 

1  of 

4 

paths 

tested 

) . 

Figure  31-31.  Instrumentation  Tool  Testing  Summary  for  test  1  .lex  and  sample.lex 
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MB  1 1  _p)cg_d«c  1  ■ 

•mit_p«tt*rn_n«M ; 1 

•iBit_«lt_caa«8 

Mnit_concat_caa«a 

ainit_patt8rn_iaacch 

amlt_char 

amit.aalact 

ami t_acan_proc 

Mnit.cokan 

includa_pactarn 

looK_up_pat  tarn 

option 

rapaat 

acora_pattern 

lltakaaction 

Tha  following  atodulaa  have  full 
llfind 
llnext token 
araaa 
llmain 
ll_campile 
get_char 
char_advance 
look_ahead 
emi  t_advanca_hdr 
ami t_advanca_t 1 r 
amit_coneat_right 


{ 

1 

of 

3 

paths 

tasted 

)  . 

( 

3 

of 

4 

paths 

tasted 

)  . 

( 

3 

of 

4 

paths 

tasted 

)  . 

( 

4 

of 

5 

paths 

tasted 

)  . 

( 

12 

of 

19 

paths 

tasted 

1  . 

( 

2 

of 

11 

paths 

tasted 

)  . 

( 

5 

of 

10 

paths 

tested 

)  . 

1 

2 

of 

4 

paths 

tasted 

)  . 

( 

5 

of 

11 

paths 

tested 

)  . 

( 

1 

of 

2 

paths 

tasted 

)  . 

( 

2 

of 

3 

paths 

tasted 

)  . 

( 

1 

of 

3 

paths 

tested 

). 

( 

1 

of 

3 

paths 

tested 

)  . 

( 

2 

of 

fi  ^tha 

tested 

)  . 

{ 

35 

of 

68  paths 

tested 

)  . 

coverage : 

( 

5 

paths 

taatad  ) 

. 

( 

2 

paths 

tasted  ) 

( 

3 

paths 

tasted  ) 

{ 

1 

path 

tasted  ) 

( 

1 

path 

tested  ) 

( 

3 

paths 

tasted  ) 

( 

3 

paths 

taatad  ) 

( 

1 

path 

taatad  ) 

( 

1 

path 

tasted  ) 

( 

1 

path 

tasted  ) 

( 

3 

paths 

tasted  ) 

Figure  32-31.  continued.  Instrumentation  Tool  Testing  Summary  for  testl.lex  and  sam- 

pie.lex 


PROGRAM  DESIGN  COMPLEXITY  FOR  PROGRAM  ll.conpila 
ROOT  MODUXjE  OF  PROGRAM:  ll.con^ila 

DESIGN  COMPLEXITY  SO:  253 

TESTED  DESIGN  COMPLEXITY:  137 

INTEGRATION  COMPLEXITY  SI  (•  OF  SUBTREES) :  197 

TESTED  INTEGRATION  COMPLEXITY:  89 


Figure  32-32.  Instrumentation  Tool  Design  Integration  Testedness  for  testl.lex  and  sam- 

ple.lex 
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bagln 

tow  tm  I; 

BIQB  i«  liLTABLUZU  ♦  1| 
whi.1*  LOW  /m  tarn  loop 

MZsroxaT  <-  (bioh  *  low)  /  2t 

it  JTMtt  <  LLSnaOLTABUKMXWOZlID.XXT  than 
HZOB  :■  KXSWOZMT} 

•Islf  zm  -  LL8YMB0LTJUUil(MZII»0ZWT).nr  than 
if  LLSnaOLnBLKMXOPOZVD.KZlQ)  ■  WBZCH  tbu 
r«tura(  MZOVOZm  ); 

else 

retuxaC  0  )j 
end  if; 

else  —  ITEM  >  LLSYMBOLTABLECMIDPOZHT)  .KEY 
LOW  I-  NZOPOZMT  4  1| 
end  if; 
and  loop; 

rotuxn(  0  );  —  itaa  is  not  in  tabla 

and  LLVZWD; 
bagin 

LL_TOKBIS.ADVnaCI(  LLEOTOKE.  LLCORTOK  ); 
if  LLIOTOKS  than 

LLCOllTOK.nzWTVMAB  l-  (LLSnUOraE'MUMI  ■>  '  '); 
LLcimK«.maivALai(i..5)  *■  "(aof}"; 

LLCORTOK. TEBLETWtMtX  t-  LLL0CB08; 
and  if; 

and  LUBXTTOKn; 
bagin 

nODOCTZOHS(WHZCB»ROD) .SHE  tm  TBZERBS  4  1; 

CHZLDCOOWT  tm  0/ 

for  Z  in  «>Z8RRS4l  ..  TBZERBS4PR0D0CTZ0ia(WHZCHPR0D).CR»SWHE  loop 
if  Z  <■  LLRBSSZIl  than 
THZESHS  «■  TBZSRBE41; 
aiT(  LLCaiRK,  CB  ); 

oaaa  CH  is 

when  ' 1 '  a> 

CBZLDCODRT  t-  CBZLnCODWT4l; 

RHSMaULT(Z) .WHZCMCHZLO  t«  CEZLOCOOWT; 

RBSR1I1U.T(Z).XZKD  i-  LZTBRRL; 

QBTC  LLORRM,  RBSARMTCZ)  .TABLEZBEU  ); 

when  'a'  s> 

lt>SJUaU.T(Z).XZWD  t>  ACTZOW; 
when  'n'  » 

CHZUXXXnR  t-  C>ZLDCOaW*4l; 

RHEMaUT(Z)  .WHZCHCHZLP  t>  CEZLOCOOWT; 

RBERRRAT(Z).KZWD  tm  WOOTKMnWRL; 

QET(  LLORAM,  RHSMRRTd)  .TABLBZnSZ  ); 

when  'g'  «> 

CEZLOCODWT  tm  CRZLDCOOWT41; 

RBSARRRT(Z) .WBZCRCHZLD  tm  CHZLDCOOWT; 

RHSARIIAT(Z)  .XZWD  •-  OROOP; 

QBT(  LLORMI,  RBSMRXT(Z)  .TABLEZWDBZ  ); 
when  'p'  s> 

RBSARRAT(Z) .KZRD  ;■  PATCH; 
when  others  s> 

—  the  llgram  table  is  screwed  up 
POT(  STANDARD_ERROR, 

••••  Zuse  —  Error  in  table  file  (360)  ) ; 

raise  PARSING_ERROR; 

and  oaaa; 

if  BHD_aF_LZHB(  LLORMI  )  than 
RBSMIRAT(Z) .CRSHZWOEX  tm  0; 

else 

aBT(  LLQRAM,  RBEARRAT(Z) .CASEZHOEX  ); 
and  if; 

if  EHD_OP_LZHE(  LLORMI  )  than 

Figure  32-34.  SLICE  Listing  Excerpt 
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RBSMUtATd)  .SnOtZHSBX  t-  0; 


else 

0IT(  LLGUM.  SKSAlUtAr(Z)  .8TVCHZKDEX  ); 

end  If; 

8KZP_LXn(  UiOMkM  ); 
else 

—  llgram  table  is  screwed  up 
PUT_LINE(  STANUARD.EIWOR, 

•***  zuse  —  Error  in  cable  file  (372)  ); 

—  This  is  a  catastrophic  error  —  the  gramnar  used  to 

—  generate  the  compiler  probably  contained  errors, 
raise  PARSING_ERROR; 

end  If; 
end  loop; 
end  BOZUKZORT; 
hscfln 

mODOCTX(aiS(MHZCHPllOO)  .SSLSIT  tm  (oCbere  »  PALSB) ;  —  e^pty  set 

for  Z  In  1  ..  ni01XICTZ0M5(mZCHPK0D).CniU>8BIi  loop 
QIT(  LLQMM.  TABUBZHDBC  ); 

PR0I10CTZQMS(mZCBni0D).8BL8>T(T*BLBZnDIX)  TBOB; 

and  loop; 

SKZ»_Man(  lAjaUM  ); 
end  BOZLOSBLKT; 
begin  —  mbPanMI 

OPBK  VLOUM.  lajriLt,  ■TABLB-  ); 

—  read  in  symbol  cables 

for  z  in  1  ..  LLTABUSZU  loop 

for  J  in  1  ..  UiSmzmUBQTB  loop 

QITC  LIAMIf.  Ui8niB0&TABU(I)  .nT( J>  )/ 

end  loop; 

an(  LLORMI,  09  ); 

SXZP_liZKB(  XiIAMM  ); 

if  CB  ■  'g'  Chan 

tJ.8niB0LTABLI(Z)  .XZMD  to  OROOP; 
else  —  assume  ch  =  1 

UbSyilBObTABUKZ)  .XZIID  to  LZmUU.; 

end  if; 


end  loop; 

--  read  in  gramnar 

THZSRBS  to  0; 

aR(  LUBUM,  AXZCM  ); 

8XZP_LZin(  LZiORAK  ); 
for  Z  in  1  ..  LIJROUBZXX  loop 
aiT(  UjORAM,  FXOXXXinOHSd)  .IA8  )f 
aBT(  LLORMI,  PRODOCTZ<ai8(X).CRRSnBS  ); 
aiT(  UiGRAM,  niODOCTZONS(Z).CRX]>S8Ii  }; 

8XXP_IiZXB(  UiOXAM  ); 

BUZUlRZaHT(Z) ; 

BUZLDSXUICTCZ); 
end  loop; 

—  now  read  in  synchronizaticm  info 

for  Z  in  1  ..  tibfffXCBSZZB  loop 

aiT(  UiOUN,  sncBDBTACD.TOKBB  };  —  llBynboltabld  location 

aBT(  LUBUM,  8TBCXDBTA(Z)  .8BBT  );  —  ayabol  to  skip  to 

8XZP_I>Z1IB(  bLORAK  ); 
and  loop; 

CU)8B(  bXiGBBX  ); 


and  HBBOORAM; 
bagin 

—  only  erase  if  at  farthest  point  to  the  right  in  a  production 
lAila  LLSTBCX(XiL8BKTPtIl)  .lABTCBXLO  loop 
—  erase  rbs 


IibSBMTPn  to  Iib8TACX(XibSX«TPTB)  .PARBMT; 
if  bUmnPTX  o  0  then  —  Btack  ia  a^pty 
XiLTOP  I-  0; 

hLKOVMMCB  to  rJdtSt;  —  don't  try  to  advance  beyond  axiom 


Figure  32-34.  continued.  SLICE  Listing  Excerpt 
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traqcMU  ll_aMplla 

XltM  W 

OntMtad  CyslMMtle  aca»k  *itp*xl«paM4 
CyeXaMtla  5 
tMmeial  4 
Dul«a  1 


ll/ll/M  11:1S:2X 
tuyutavoMd 
uptwitf  rxoM* 
bM*  tiitt* 
tlaln  C«tf  t 


Figure  32'3S.  SLICE  Plotted  Excerpt 
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kultdrttkt  (U 


llitSsZl 


(u^rtMpaaM 

DfetMCad  Cirvlonttle  Onph  MfaxKwoMd  U|PMr4  rlom 

CysloMttc  10  beep  Exit* 


66 


Original  LLFIND  in  fil*  ll_caa^il*.a: 

function  LLFIMDC  ITEM:  LLSTRINQS:  WHICH:  LLSTYLE  )  raturn  INTEGER  is 
—  Find  itan  in  syaibol  tabla  —  ratum  indax  or  0  if  not  found. 

-•  Aasunas  syaibol  tabla  is  sortad  in  ascanding  ordar. 

LOW,  MIDPOINT,  HIGH:  INISOSR; 
bagin 

LOW  :a  1; 

KICK  :s  LLTABLBSIZB  *  1; 
wbila  LOW  /a  RICH  loop 

MIOPOQir  :«  (HIGH  *  LOW)  /  3t 
it  ITB<  <  LLSYMBOLTABLE (MIDPOINT)  .KEY  than 
HIGH  :-  MIDPOINT; 

alsif  ITEM  «  LLSYMBOLTABLE (MIDPOINT) .KEY  than 
if  LLSYMBOLTABLE (MIDPOINT) .KIND  -  WHICH  than 
ratum  (  MIDPOINT  ): 

alsa 

ratum  (  0  )  ,- 
and  if; 

alsa  —  not  >  LLSYMBOLTA8LB(MIDPOIMT)  .KEY 
LOW  :«  MIDPOINT  4  1; 
and  if; 
and  loop; 

raturn (  0  ) ;  —  itan  is  not  in  tabla 

and  LLFIND; 


Hodifiad  LLFIND  in  fila  adit_ll_carDpila.a: 

Fron  adlt_l_caaDpila.a: 

function  LLFIND (  ITEM:  LLSTRINGS;  WHIC3I:  LLSTYLE  )  ratum  INTEGER  is 
”  Find  itan  in  syabol  tabla  --  ratum  indax  or  0  if  not  found. 

—  Assusws  syabol  tabla  is  sortad  in  ascanding  ordar. 

LOW,  MIDPOINT,  HIGH:  INISGER; 
bag  in 

LOW  :>  1; 

HIGH  :«  LLTABLESIZE  *  1; 
whila  LOW  /«  HIGH  loop 

if  ITOi  «  LLSYMBOLTABLE (LOW) .KEY  than 

if  LLSYMBOLTABLE (LOW) .KIND  >  WHICH  than 
ratum  (  LOW  )  ; 
alsa 

ratum  (  0  ) ; 
and  if; 
and  if: 

LOW  :s  LOW  *  1; 
and  loop; 

raturn  (  0  ) ;  —  itaai  is  not  in  tabla 

and  LLFIND; 


Figure  32-36.  CodeBreaker  Original  and  Modified  Module  LLFIND 
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HOOULE  COMPARISON 

BSSS3S3atSSSXSSSSSSS  =  SSS  =  X3=« 


FILE:  /•vaX/Bccab«/work/ll_coiBpil« 

.a 

MODULE:Ufind 

sasswsaissssssasmaassaisssssss. 

llfind  I  001  lllllndil 


I  FILE:  /aval/mccaba/viork/edit_ll_ 
I  npila.a 

IHOOULE:  llfind;  1 


sscmaaaasssassBsaasaaBB 


148:  low  /3  high  FALSE 
163:  <raturn> 

*  HATCH  * 

aaaBBBaBaBBBBBaBBaBBBBaaaBBBa 

llfind 


I  148:  low  Jm  high  33>  FALSE 
I  159 :  <raturn> 


I  002  I llfind;! 


148:  low  />  high  «»  TRUE 
150:  ican  <  llaynboltabladnidpoin' 
t) .kay  B«>  TRUE 
*•*  MISMATCH 


148:  low  /=  high  »>  TRUE 
149:  itan  b  llsyadooltabladow) 
==>  TRUE 


key 


llfind 


taaBaaBBaBBBaBaBBBB 

I  003  I llfind;! 


■BaBBBaBBBaaBBBBBa 


148;  low  /=  high  BB>  TRUE 
150:  itam  <  llsymboltabla (nidpoin' 
t) .key  >s>  FALSE 
*•  MISMATCH  •** 


148:  low  /b  high  bb>  TRUE 
149:  item  s  llaynboltabla(low) 
BB>  FALSE 


kay 


llfind 


I  004  I llfind;! 


148:  low  /b  high  bb>  TRUE 
ISO:  item  <  llsymboltabla (midpoin* 
t) .key  BB>  FALSE 
'•  MISMATCH  ••• 


148:  low  /b  high  b.>  TRUE 
149:  itam  b  llsymboltabla (low) 
x3>  FALSE 


kay 


xsssasss 


llfind 


I  005  I llfind;! 


148:  low  /b  high  bb>  TRUE 
ISO:  item  <  llsymboltabla (midpoin' 
t) .key  BB>  FALSE 
*•  MISMATCH 


148:  low  /b  high  bb>  TRUE 
149:  item  b  llsymboltabla (low) 
BB>  FALSE 


kay 


ANALYSIS 


Number  of  basis  paths:  5 
Number  of  suttchas:  1 
Number  of  mismatches:  4 
Quantitative  level  of  coarnmnality:  0.20 
Qualitative  level  of  ccnsaonality :  LOW 


Options:  NO  OBSIQN  REDUCTICW 


Figure  32-38.  CodeBreaker  Comparison  of  Modified  Against  Original  LLFIND 
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1 


^BsasasssssssssssssassssssssssssssssssssssssssssssssssmsssBssssssssassssssss 

I  MODULE  COMPARISOH 

^asBasBBaBBBSBassaasBaaaasaBSBasasssBsxBSBBBBBSBBaaBsssaaaaxassssssssassBsss^ 

^BsBBaBSBBaaBSSBBBasaaasaaaassaazsssssasssassBssBBSBBSBBBSSBBBmasxaBBBSBBsss^ 

IPILE:  /aval/Kccabs/work/adit.ll.co*  IPILE:  /•val/Bcc«b«/t«ork/ll_compile~  l 
I  Bpil*.*  I  -a 

IMODULE;llfindil  IMODULE: Ilf ind  i 


llfind;! 

1  001 

lllfind 

148:  low  /x  high  xx>  FALSE 

1 

148: 

low  /x  high  xs>  FALSE 

159:  <raCurn> 

1 

163; 

•  MATCH  * 

1 

Rsass 

llfind;!  I  002  lllfind 


148:  low  /x  high  >»  TRUE 

149:  it«n  *  llaymboltabla (low) .kay 
xx>  TRUE 

MISHXTCH  ••• 


148;  low  /c  high  ==>  TRUE 

ISO:  itam  <  llayB:boltabla(midpoin 
t) .kay  3x>  TRUE 


llfind;!  I  003  lllfind 


148:  low  /■  high  =='>  TRUE  I  148:  low  /m  high  xk>  TRUE 

I 

149:  itam  x  llaynbolcabla(low) .key  I  150:  itan  <  llaynboltabla (aidpoin* 
xx>  FALSE  I  t) .kay  xx>  FALSE 

I 

MISMATCH  •••  I 

XXaXXXXXSSXXSSSaXXXXXXXXBXXXSXXaXXtMXXXSXXXSXXBXXXXXXXXKXXXXXXXXXXXXSSSXSXXX 

llfind;!  I  004  lllfind 


148:  low  /x  high  xx>  TRUE  I  148:  low  /s  high  xx>  TRUE 

I 

149:  itam  «  llsyaboltobladow)  .kay  I  150:  itam  <  llayaboltablaiaidpoin" 
xx>  TRUE  I  t) .kay  xa>  TRUE 

I 

•••  MISMATCH  •••  I 


4-xssxX3xaxxxxsaxxa«saasaxa3sxxxxssxxxxaxxxxxxxxxxxxxaxxxaxxxsxxxss=s===saxsx-4> 
I  AKALYSIS  I 


Nuabar  of  baaia  pacha:  4 
Nuabac  of  aacchaa:  1 
MUnibar  of  aiaaaCchaa:  3 
QuanCitativa  laval  of  coanonality:  0.25 
QualitaCiva  laval  of  coamonality:  MEDIUM  LOW 


Options :  NO  DESIGN  REDUCTION 


Figure  32-39.  CodeBreaker  Comparison  of  Original  Against  Modified  LLFIND 


170 


PROGRAM  COMPARISON 


IFILE:  ll.conpil* 

(ROOT:  ll.conpila 


ll_caapil« 


IPZLE:  ll_coa(>il*_2 
IROOT:  ll_coaipil*_2 


I  001  IPILB:  ll_eoapil«_2 


rMdgramO 

466:  i  in  1  ..  lltablcais*  «*>  FA* 
LSE 

482:  i  in  1  ..  llprodais*  »>  FAL* 
SE 

491:  i  in  1  ..  llaynchaic*  FA~ 
LSE 

llfindO 

148:  low  /s  high  FALSE 

148:  low  />  high  >«>  FALSE 
advanca ( ) 

200:  (currant.char  s  aacii.atx)  or 
(currant_ehar  a  aaeii.ht)  or 
(currant_chat  >  '  ' )  os  (cus" 
rant_char  «  ' - ' )  «»>  FALSE 


•••  MISMATCH  ••• 

sasssssssasasscsssa 

FIIX:  ll_conpil« 


raadgram( ) 


raadgranO 

466:  i  in  1  ..  lltablaaica  aa>  FA* 
LSE 

482:  i  in  1  ..  llprodaica  aa>  FAL* 
SE 

491;  i  in  1  ..  llaynchaiaa  »>  FA* 
LSE 

llfindO 

148:  low  /a  high  *=>  FALSE 
148:  low  />  high  ma>  FALSE 
acaii_pattarn  ( ) 

12S:  scarc.of.lina  ss>  FALSE 


I  002  (FILE:  ll_coapila_2 


IraadgraaC ) 


llfindO 

148:  low  /a  high  aa>  FALSE 


466: 

i  in 
HE 

1 

.  lltablaaisa  aa>  TR~  1 

1 

466: 

i  in 
UE 

1  . 

.  lltablaaisa  aa>  TR~ 

467: 

j  in  1  . 
FALSE 

.  1 latringlangch  aa>  | 

1 

467: 

j  in  1  . 
FALSE 

.  llatringlangth  sa> 

472: 

ch  = 

'g' 

=a>  TRtlE  1 

472: 

ch  a 

'g' 

aa>  TRUE 

466: 

i  in 
LSE 

1 

.  lltablaaisa  aa>  FA'  1 

1 

466: 

i  in 

LSE 

1  . 

482; 

i  in 
SE 

1 

.  llprodsisa  aa>  FAL*  1 

1 

482: 

i  in 
SE 

1  . 

.  llprodsisa  aa>  FAL* 

491; 

i  in 
LSE 

1 

.  llayncbaisa  aa>  FA~  1 

1 

491: 

i  in 
LSE 

1  . 

.  llsynchsisa  aa>  FA~ 

llfindO 

148:  low  /a  high  aa>  FALSE 


Figure  32-40.  CodeBreaker  Program  Comparison 
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Figure  32-4U.  continued.  CodeBreaker  Program  Comparison 
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ACRONYMS  AND  ABBREVIATIONS 


ACT 

ADADL 

ADAMA 

ATA 

ATH 

ATI 

BAT 

BMD 

BMDO 

CASE 

CRWG 

DDTs 

DFD 

DEC 

ESD 

GKS 

GPALS 

IBM 

IDA 

IEEE 

LCSAJ 

LDRA 

MALPAS 


Analysis  of  Complexity 

Ada-based  Design  and  Documentation  Language 

Ada  Measurement  and  Analysis  Tool 

AdaTEST  Analysis 

AdaTEST  Harness 

AdaTEST  Instnimentor 

Batdemap  Analysis  Tool 

Ballistic  Missile  Defense 

Ballistic  Missile  Defense  Organization 

Computer-aided  Software  Engineering 

Computer  Resources  Working  Group 

Distributed  Defect  Tracking  System 

Data  Flow  Diagram 

Digital  Equipment  Corporation 

Electronic  Systems  Division 

Graphical  Kernel  System 

Global  Protection  Against  Limited  Strikes 

International  Business  Machines 

Institute  for  Defense  Analyses 

Institute  for  Electrical  and  Electronics  Engineers,  Inc. 

Linear  Code  Sequence  and  Jump 

Liverpool  Data  Research  Associates 

Malvern  Program  Analysis  Suite 


PC 

Personal  Computer 

PDL 

Program  Design  Language 

QA 

Quality  Assurance 

RADC 

Rome  Air  Development  Center 

StP 

Software  through  Pictures 

SDI 

Strategic  Defense  Initiative 

SPC 

Software  Productivity  Consortium 

START 

Structured  Testing  and  Requirements  Tool 

TBGEN 

Test  Bed  Generator 

TCMON 

Test  Coverage  Monitor 

TST 

Test  Support  Tool 

US 

United  States 

VDM 

^enna  Development  Method 
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